Multi server support

[theothornhill]

Hello there!
I've been looking through other issues and PR's from earlier mentioning multi-server support. It doesn't seem to be a trivial thing to add to eglot as far as I can tell from your comments, but I believe it's a useful one.

The easiest example where multi-server support is wanted I can come up with is JavaScript and ESlint, notably the typescript-language-server and vscode-eslint. Many of the important code actions during for example React development relies on the ESlint server.

Is this something that could only be fixed by your earlier mentioned "server multiplexer program"?

[joaotavora]

Is this something that could only be fixed by your earlier mentioned "server multiplexer program"?

Not really, it could also be fixed by something else, like overhauling eglot.el's code to send two requests instead of one every time, and expect two responses.

But I think it's much cleaner to do the "server multiplexer". One way of the other, someone has to do the work. If you know Python, I encourage you to get started on the latter: I think it's the language to use for that development.

Where is the other issue, by the way? Can you link it here?

[theothornhill]

Just to be clear - you mean a program that would accept one request from Eglot (or other lsp clients), route that request to several servers, merging results from both and ship them back as one lsp compliant response to Eglot?

I just wonder whether this is something that is wanted from other lsp clients, since many of them already support multi server files.

You talked about it in #249, #180, #90 - where the last one seems like the most fruitful discussion.

[joaotavora]

Just to be clear - you mean a program that would accept one request from Eglot (or other lsp clients), route that request to several servers, merging results from both and ship them back as one lsp compliant response to Eglot?

yes

I just wonder whether this is something that is wanted from other lsp clients, since many of them already support multi server files.

Well, no idea if that is wanted by them, but I think this would be the best way to do it, because it's client-independent, and pretty clean. But I've never tried it, it's vapourware :-)

You talked about it in #249, #180, #90 - where the last one seems like the most fruitful discussion.

Yes, I had a feeling there was an issue for that already. Let's close this one then.

[joaotavora]

I've found some time to work on this. So I'm reopening, converting this to a conversation and linking all (or most) other issues here.

[garyo]

Another use case: C++ with clangd and a copilot (TabbyML or others). Can't wait for this!

[anarcat]

Trying to figure out if eglot supports multiple LSPs, and I'm a little confused as I read in #90 (comment) that "this supported by eglot-alternatives", yet this issue here seems to say it isn't...

My use case is to run ruff alongside pylsp to both have the linter/formatter (ruff) available while having another tool (pylsp) do the classic completion stuff...

[jsadusk]

@anarcat for what you're trying to do you don't actually need this functionality. pylsp can load ruff as a plugin, and then eglot can use it as a single LSP server. Alternatively, you could use ruff in non-lsp mode as an flymake checker.

My use case is that the company I work for uses a commercial linting tool called trunk. Its a cross language meta linter, and it only provides an LSP interface. It does not provide any completion functionality. I'm developing both python and rust, and to be able to use the company wide linting rules, I need to be able to run the trunk lsp server alongside either a python or rust completion lsp (I'm using jedi-language-server and rust-analyzer).

I'm actually back using eglot because it is just better than lsp-mode, especially running over tramp. I'm running trunk as a command line utility to get results, but I really miss having inline checking. I tried using a couple lsp proxy projects, I haven't gotten any of them to work.

The use case of linters that provide an lsp interface separate from your completion server seems to be growing. This will be amazingly useful functionality when its implemented.

[anarcat]

that's really nice to hear, all this is kind of confusing to me, so i'm really glad i got this clarified...

(for what it's worth, i'm currently using lsp-mode, but that's just historical inertia on my part, i think, now that eglot is in emacs, i'll try to switch over but, alas, that's just ... work...)

[LionyxML]

Trying to figure out if eglot supports multiple LSPs, and I'm a little confused as I read in #90 (comment) that "this supported by eglot-alternatives", yet this issue here seems to say it isn't...

My use case is to run ruff alongside pylsp to both have the linter/formatter (ruff) available while having another tool (pylsp) do the classic completion stuff...

I think it means: it supports multiple LSPs, but only ONE per buffer, so you can have typescript support in a buffer and pyright on another, but not composable (typescript + tailwind, for example) on the same buffer (as lsp-mode supports).

[farynaio]

Typescript/ES6 + Tailwindcss, another good example

[LionyxML]

Regarding multiple servers per buffer, I would add some of my daily use cases:

• typescript (tsls server), eslint (as a lsp server, much faster), and tailwind
• typescript (tsls server), biome (as eslint replacement written in rust, thus faster), and tailwind
• typescript (tsls server), vls (Vue.js server), eslint/biome and tailwind
• htmx-lsp, tailwind, html (from vscode-html-language-server) and or cssls