Support for multiple language servers for one language?

[sentriz]

hi!

coming from nvim, I am used to having multiple language servers for one given language. for me it's usually a combination of a main language server for completion, jump to def, etc and efm-langserver for linting or formatting that the main server doesn't support

for example I like to use

• typescript: tsserver + efm (with prettierd for formatting, and eslint)
• python: pyright + efm (with black for formatting, and pylint)
• sql: sqls + efm (with pg_format for formatting)
• go: gopls + golangcilint-lsp
• dockerfile: docker_ls + efm (with hadolint)

so personally I think multiple servers allows for some very powerful combining of servers and cli linters / formatters using efm (sometimes the main lsp can do formatting, but it's not the formatter I want to use)

hope this makes sense and seems useful. thanks!!

[David-Else]

It seems this is very much needed, unless I am missing some other way of doing things?

For example, having eslint running in the editor is pretty much essential for JS/TS, it is available as a language server directly from VS Code via https://www.npmjs.com/package/vscode-langservers-extracted , but how can we run it with https://github.com/typescript-language-server/typescript-language-server and the same time?

[Philipp-M]

I've started tackling this in #2507, feedback welcome

[losnappas]

Just thinking out loud here: couldn't this problem be solved with an in-between proxy lsp that forwards requests to multiple lsps? Because this problem is not only in helix (e.g. emacs eglot joaotavora/eglot#976 ), would be nice to solve this sort of thing once and for all. However, my lsp knowledge is zero so maybe there are blockers that I don't know of.

[ghost]

Is it not a better idea to make a language server that does this for a use case and configure helix to use that directly? Say you're using HTML, CSS, and JS in one project (some in the same file, like JSX or <script>). There could then be a webls that provides this kind of thing, neatly integrated with all of the intelligence for that domain baked into the single server.

For use cases where some functionality is provided by one and the rest by another, shouldn't the maintainers of these servers provide options to allow you to use "feature set A" for certain operations? For example the LS for javascript should provide an option to get lints from somewhere else, keeping the craziness of javascript tooling confined to the language server and not allowing it to spill over into every single editor that supports LSP. The benefit here is that anyone using an LSP-aware editor gets the spoils right away, which is one of the purported benefits of the LSP approach to begin with.

My worry is that this will be error prone, buggy, slow, and only work for you if you have everything configured precisely so. It's also not part of the spec, and you go against standards at your own peril.

This is also not a problem specific to helix. Any editor that claims to support LSP will eventually get an issue like this opened, and have to implement non-standard hacks on top of the usual LSP support to get it "working".

[d4h0]

@adam-becker: Is there anything in the LSP spec that says that a document can't have several language servers? If not: How does implementing support for several servers go against the standard?

Also: What about language servers for general use-cases, like spell-checking? Should spell-check LSP servers somehow embed all other possible LSP servers? Or should all other LSP servers implement an option for the spell-checking LSP servers?

In theory, there probably could be some kind of reverse-proxy for LSP servers, but I doubt that would result in a better experience than something that is built into the editor itself.

[ghost]

@adam-becker: Is there anything in the LSP spec that says that a document can't have several language servers? If not: How does implementing support for several servers go against the standard?

The spirit of the standard is that 1 language server provides functionality for 1 language (Ruby language server covers all of Ruby). The point is to contain/encapsulate/whatever all of the domain logic and knowledge for a programming language. Having multiple is not called out, and a lot of the request/response architecture that exists would be broken in the presence of this paradigm. So, it's not explicitly noted as being impossible, but on the flip side it's also not explicitly supported and would be an extension to the standard at best.

Also: What about language servers for general use-cases, like spell-checking? Should spell-check LSP servers somehow embed all other possible LSP servers? Or should all other LSP servers implement an option for the spell-checking LSP servers?

Straw man argument, spell check isn't required to support language X. Editors far and wide support spell check with the myriad libraries that offer this. Spell check is also not a language, and therefore has no business being involved in the LSP discussion.

In theory, there probably could be some kind of reverse-proxy for LSP servers, but I doubt that would result in a better experience than something that is built into the editor itself.

How? It's the exact same functionality, just moved into a product that all LSP-aware editors can use instead of individually hacking this functionality into each and every editor. This "editor X has to support feature Y to get language Z" is exactly why LSP was created in the first place. Going back to that pattern and adding complexity to support an edge case is naive. It makes no difference that some editors already made this bad decision, it's still a bad decision.

EDIT: I also have no interest in starting a holy war about this. I have my opinions, and I raised concerns that arose from those opinions. This will be my last post/response on this topic, the maintainers of helix are of course free to do as they wish.

[bushblade]

@adam-becker I think web development would be a good example.
Say someone were to write a webls language server, how does the webls creator know what the developer chooses to use?
Currently you could need one for TypeScript/JavaScript another for HTML another for CSS, but then what if you're using Vue - you need VLS or some other single file component language? using ESlint? another language server, what about Tailwind? SASS? Astro? CSS in JS? There are almost endless possibilities of what the stack could be all in one file type. Should there be one language server that covers every possibility?
Or should each language have it's own server that can be composed together with others which is what we see currently used in other editors.

[Philipp-M]

My 2 cents to this topic.

Having a proxy language server seems like a good intermediate solution for editors that have no multiple LSP support, but having actual multiple LSP support in the core of the editor has a few advantages (probably more):

• No unnecessary deserializing/serializing (to and from the proxy) and separate process/context switches etc. This is mostly performance related, and probably not that important as other stuff most likely eats up most of the processor time
• Being able to better handle UI and other stuff separately like e.g. a tab indicator for the "hover" doc for different language servers
• Having one instance of a language server that is able to catch the (context of the) whole project, across multiple languages. Having a proxy that is configured separately for languages will likely require multiple proxy instances for different language server configurations (e.g. vue needs vls and maybe eslint, typescript, tls and eslint etc.) While you likely just want one instance of a language server (in the example eslint)
• Or an artificial example: having a spellchecker language server, which is displayed in the status line (but only this language server) and is active for every file, additionally to the other language servers used there.

[d4h0]

@adam-becker:

The spirit of the standard is that 1 language server provides functionality for 1 language

And yet you propose to combine several language servers into one.

on the flip side it's also not explicitly supported and would be an extension to the standard at best.

And handling several languages in one LSP server wouldn't be an extension to the standard? If anything, that would be even worse.

Straw man argument, spell check isn't required to support language X.

How is that a straw man argument? This is literally the use-case why I'm interested in support for several LSP servers, and why I responded to your comment.

Spell check is also not a language, and therefore has no business being involved in the LSP discussion.

What are you trying to say here? That human languages are no languages? LSP servers are not languages, they offer tools to work with languages. And human languages obviously are languages.

Spell-checking is a perfect use-case for LSP (I hope I don't have to waste time explaining why).

Editors far and wide support spell check with the myriad libraries that offer this.

So you propose to not include support for multiple LSP servers per document into every editor so that this functionality isn't duplicated for every editor. And in that process you dismiss valid use-cases like spell-checking, which every editor should implement on their own, or via plugins. Do I get that right?

In theory, there probably could be some kind of reverse-proxy for LSP servers, but I doubt that would result in a better experience than something that is built into the editor itself.

How?

Potential issues regarding performance and offering a great UI are pretty obvious. The other things you wrote in that paragraph make no sense.

I have my opinions, and I raised concerns that arose from those opinions.

Yes, and it shouldn't be surprising if others do the same in regard to your opinions and concerns... ;)