Re-use running LanguageTool process

[austinbutler]

Is your feature request related to a problem? Please describe.

LanguageTool uses a lot of RAM.

Describe the solution you'd like

The RAM usage of LanguageTool itself is outside of your control, but I notice if I have separate Neovim instances they each start their own LanguageTool process.

procs --no-header ltex | wc -l
2

So would it be possible to first see if there's already a running process, then work with that process?

Describe alternatives you've considered

I could run LanguageTool as a server, but it's more complicated (have to either remember to start it manually or if I start it automatically with my computer I'm always using that extra RAM even when I don't need it).

[alberti42]

I recently created a package for Emacs and looked deeper into the LSP mechaincs: https://github.com/alberti42/emacs-ltex-plus

I did not check at at all the Neovim package. But here is my guess. The Neovim package is not using the multi-root capability of the LSP server.

The workspaceFoldersOptions capability was always there, but not advertised. The previous Emacs package did the same "mistake" and started a new server for each file, which is clearly unbearable.

I just created a PR #152 where the capability is properly advertized:

workspaceFoldersOptions.supported = true

It would be great to get in contact with the developer of the Neovim package and check whether they are aware of this. You could send him/her the link above to PR, which contains detailed information for developers of the LSP client counterpart.

You are welcome to reopen the issue if you think I missed something.

[alberti42]

I am sorry, after closer inspection, I found a bug in the code that would not allow you to connect to the LTeX+ daemon with two different Neovim sessions. I will check if I can make a PR to fix the bug. So I reopened the issue.

[David-Else]

I don't think this is working in Helix. I tried the latest:

{
  "ltex-ls": "18.7.0-alpha.nightly.2026-04-22",
  "java": "21.0.10"
}

and run watch -n 1 'pgrep -afl "ltex" | grep -v watch | wc -l'

When I open any number of markdown documents in a project folder the number remains at 1. If I open another kitty tab and another project in Helix, when I open another markdown file the number increases to 2. I expect it to stay at 1.

This is from Helix log, so it is getting some info about workspace folders okay:

2026-04-23T19:32:09.010 helix_lsp::transport [INFO] ltex-ls-plus <- {"jsonrpc":"2.0","id":0,"result":{"capabilities":{"textDocumentSync":1,"completionProvider":{},"codeActionProvider":{"codeActionKinds":["quickfix.ltex.acceptSuggestions"]},"executeCommandProvider":{"commands":["_ltex.checkDocument","_ltex.getServerStatus"]},"workspace":{"workspaceFolders":{"supported":true,"changeNotifications":true}}}}}

[alberti42]

When I open any number of markdown documents in a project folder the number remains at 1.

This is good, and it is also expected for an LSP client not to start a new server for each file within a project. Anything else would be very wrong.

To be clear, whether it remains 1 or it becomes 10 after opening 10 files is nothing controlled by the server (this project); it was always the client's responsibility (the Helix lsp package).

If I open another kitty tab and another project in Helix, when I open another markdown file the number increases to 2. I expect it to stay at 1.

Yes, I also expect it to stay at 1 for a spell checker. This is arguably a bug. It makes no sense that you populate in your RAM tens of virtual Java machines, each taking 500 MB!

Who wrote the package did not realize that it is possible to tell LTeX to share the same root. The same mistake was made by the predecessor of the package I wrote for Emacs. In my view, it is a deal breaker.

The reason why this happens is that most of LSP servers are developed for working on multi-file projects. You want to keep your projects separate. Normally, an LSP server scans and indexes your relevant files with lines of code and finds connections, etc. But for a spell checker, this is the wrong approach. A spell checker is more similar to a linter. There is no limitation from the server side to just use a single process. VS Code does it, my Emacs package does it. We would have to look how the Helix package was written.

The good news: In Emacs, this can be fixed with one line:

    :multi-root lsp-ltex-plus-multi-root

Hopefully in the Helix package you can do the same with one line. There was something missing on the server side, namely the fact that this capability was not advertised correctly. I wrote a PR which is now upstream (#152) to exactly do that. But the PR is just cosmetic, because it only tells future developers that this functionality is supported. It was always supported even before; you don't need the nightly install.

PS: It is great if you use nightly install, so if you find some bug, you can report back, ;-) and I am glad to fix them, but I am afraid for your specific problem, we would have to look into the Helix package.