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

Support having multiple paths #55

Closed
Kayzels opened this issue May 21, 2024 · 2 comments
Closed

Support having multiple paths #55

Kayzels opened this issue May 21, 2024 · 2 comments

Comments

@Kayzels
Copy link

Kayzels commented May 21, 2024

I've switched over almost entirely to Neovim, but still have some old files using the .vscode directory, so have path set to use that. However, I'd love to be able to set path to be something like .ltex instead, but still be able to use the files already existing in the vscode directory.

Describe the solution you'd like
It would be great to define a default path to look for files, and that should be populated, but it should also search in other paths given to find any LTex rules files. So, it should search in .ltex first, but also search for any LTex files in .vscode, and join them together when checking. Not sure if this is something to do with ltex_extra, or the LTex LSP itself.

Describe alternatives you've considered
I haven't considered alternatives, because the current way works (with path set to vscode), so this would just be a nice to have.

@barreiroleo
Copy link
Owner

Hi @Kayzels,

Have you considered making some symbolic links from .ltex to .vscode?

I'm not sure to implement this as a feature and how beneficial it could be for all the users. I think I can expose a hook to run before the server setup so you can implement a merge function as a user.

@Kayzels
Copy link
Author

Kayzels commented Jan 10, 2025

That's a good idea. I've ended up moving away from LTeX for now, because the builtin Neovim spelling is more than enough for my needs. I wasn't aware it existed when I created this issue.

Thank you, though. We can probably close this issue.

@Kayzels Kayzels closed this as completed Jan 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants