Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LTeX+ does not start when opening a Python file despite having "python" in "ltex.enabled" #108

Open
tovrstra opened this issue Dec 23, 2024 · 3 comments
Assignees
Labels
1-feature-request ✨ Issue type: Request for a desirable, nice-to-have feature

Comments

@tovrstra
Copy link

Note: It is highly recommended to follow the instructions at https://ltex-plus.github.io/ltex-plus/vscode-ltex-plus/contributing.html#how-to-report-bugs and use the LTeX: Report bug in LTeX command from within Visual Studio Code. Per the contribution guidelines, deleting parts of the template or not filling in vital information may result in the issue to be immediately closed as invalid.

Describe the bug
LTeX+ does not start when opening a Python file. I have the following in my user settings JSON:

{
    "files.autoSave": "onFocusChange",
    "ltex.additionalRules.motherTongue": "nl-BE",
    "ltex.enabled": [
        "python",
        "bibtex",
        "context",
        "context.tex",
        "html",
        "latex",
        "markdown",
        "mdx",
        "typst",
        "org",
        "quarto",
        "restructuredtext",
        "rsweave"
    ],
}

Steps to reproduce
Steps to reproduce the behavior:

  1. Install LTeX+ extension
  2. Add python to the list ltex.enabled
  3. Restart VSCode, just to make sure the extension has not yet started for the following step.
  4. Open a Python file before opening any other files (markdown, tex, etc.)

Expected behavior
LTeX+ should start when opening a file for which it was enabled.

Sample document
Any Python file.

LTeX+ configuration
See above.

"LTeX+ Language Server" log file
The output is not present yet, because LTeX hasn't started yet.

"LTeX+ Language Client" log file
idem

Version information
List here the version information of the relevant software.

  • Operating system: Fedora Linux 41 (Linux hostname 6.12.5-200.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Dec 15 16:48:23 UTC 2024 x86_64 GNU/Linux)
  • CPU manufacturer: Intel(R) Core(TM) i7
  • VS Code: 1.96.2
  • vscode-ltex-plus: 15.3.0
  • ltex-ls-plus: not manually installed
  • Java:
openjdk version "21.0.5" 2024-10-15
OpenJDK Runtime Environment (Red_Hat-21.0.5.0.11-1) (build 21.0.5+11)
OpenJDK 64-Bit Server VM (Red_Hat-21.0.5.0.11-1) (build 21.0.5+11, mixed mode, sharing)
@tovrstra tovrstra added 1-bug 🐛 Issue type: Bug report (something isn't working as expected) 2-unconfirmed Issue status: Bug that needs to be reproduced (all new bugs have this label) labels Dec 23, 2024
@tovrstra
Copy link
Author

Workarounds are fairly easy: either open a markdown or tex file, which starts LTeX+, after which it also checks other enabled files. You can also manually start LTeX+ as follows:

  • Open the command palette with Ctrl+Shift+P
  • type LTEX: Activate Extension

@spitzerd
Copy link
Contributor

It's working as designed and documented, see https://ltex-plus.github.io/ltex-plus/vscode-ltex-plus/commands.html#ltex-activate-extension

I already made a proposal in #106 (comment):

I see your point that the logic of LTeX+ is quite weird. In my opinion, following logic is the most convenient for most of the users:
LTeX+ is activated everytime VS Code starts. LTeX+ does only check the settings of ltex.enabled, nothing else. Once a file is opened and its file type is included in ltex.enabled, the language server starts and LTeX+ starts checking. If you run LTeX : Check Document, the setting of ltex.enabled is ignored and the document is checked in any case. Consequently, there is no need for LTeX : Activate Extension anymore

@spitzerd spitzerd added 1-feature-request ✨ Issue type: Request for a desirable, nice-to-have feature and removed 1-bug 🐛 Issue type: Bug report (something isn't working as expected) 2-unconfirmed Issue status: Bug that needs to be reproduced (all new bugs have this label) labels Dec 23, 2024
@tovrstra
Copy link
Author

Thanks, and sorry for not coming back to this for a while. You're right: I missed that part in the documentation.

The quote proposal sounds good. It would indeed be more intuitive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1-feature-request ✨ Issue type: Request for a desirable, nice-to-have feature
Projects
None yet
Development

No branches or pull requests

2 participants