Consider the possibility of having multiple LSP servers for one filetype
Closed this issue · 12 comments
Right now, only one LSP server is allowed for one filetype. This could be limiting in cases when there are multiple LSP servers for a given language and each of them is better at something else so e.g. one could be used for autocompletion, the other for formatting.
This would, however, complicate the config file and it's hard to say if it's a real-life scenario. The config file would have to be updated to support more servers for a single file and allow sections like [Pascal_1], [Pascal_2], etc. for all the servers.
@techee As for me I know one language for which it really make sense - Python. For example pylsp has autocompletion (jedi), linter and formatter (ruff), static type checker (mypy), advanced refactoring (rope), but is slower than using two separate server - jedi-language-server (autocompletion, basic refactoring) and ruff server (linter and formatter). No advanced refactoring and static type checker but it can be sufficient.
I have found some info on this topic, especially seems interesting to use proxy lsp server to connect to multiple servers.
I have tried to setup multi lsp proxy in Geany but it didn't work. As I understand proxy uses websockets.
Adding Support for Multiple Language Servers to Monaco Editor
https://github.com/wylieconlon/jsonrpc-ws-proxy
https://github.com/qualified/lsp-ws-proxy
muti lsp proxy written in rust
https://github.com/messense/multi-lsp-proxy
vscode multi lsp sample
https://github.com/Microsoft/vscode-extension-samples/tree/main/lsp-multi-server-sample
So maybe it will be fine to implement websocket - issue #38 (for Godot, Multi LSP proxy)
P.S It seems that some proxies used for remote connection for lsp server and not for multiple lsp servers per language.
@techee As for me I know one language for which it really make sense - Python. For example pylsp has autocompletion (jedi), linter and formatter (ruff), static type checker (mypy), advanced refactoring (rope), but is slower than using two separate server - jedi-language-server (autocompletion, basic refactoring) and ruff server (linter and formatter). No advanced refactoring and static type checker but it can be sufficient.
You might also consider pyright which worked very well for me.
I have found some info on this topic, especially seems interesting to use proxy lsp server to connect to multiple servers.
I have tried to setup multi lsp proxy in Geany but it didn't work. As I understand proxy uses websockets.
I didn't try it but I don't think it uses sockets (or websockets). Maybe you just didn't configure it correctly.
So maybe it will be fine to implement #38 (for Godot, Multi LSP proxy)
Note that this isn't about websockets (maybe some servers support those but this is only useful for remote servers and I don't see many reasons to support those) but normal unix sockets where the server runs as a real separate server not started by the plugin and where the communication isn't possible over stdio. In any case, it has nothing to do with Multi LSP proxy which I believe should run as a normal server communicating over stdio.
If something like the proxy works, I'd prefer not to implement this feature in the plugin itself - it really complicates configuration and debugging.
Yeah, I just checked the sources, the proxy uses stdin/stdout for communication, not sockets.
Pyright works well, but it doesn't have linter and formatter such as Ruff. Pylsp has plugins for Ruff.
But it seems that Ruff server works faster than Pylsp with Ruff plugin, so ideally Jedi LSP + Ruff LSP or Pyright LSP + Ruff LSP.
So a good variant will be stdin/stdout proxy similar as https://github.com/messense/multi-lsp-proxy, I will try again to run it, seems a good idea overall.
Well, multi-lsp-proxy doesn't work for me and I don't really think it's a finished product. It should for instance merge the initialize responses from all the servers and act as a single server which it does not. Also, one should be able to configure which requests/responses should be dispatched to which server - if it sends all of them to all of the servers, you'd e.g. get autocompletion responses from multiple servers which doesn't make sense.
The idea of a proxy server is a good one though and I'd prefer implementing a proxy LSP than adding direct multiple LSP support to the plugin.
It is a pity. As I understood multi-lsp-proxy was created as potential possibility to have multiple lsp servers
in Helix, but for now Helix supports multiple lsp servers:
https://helix-editor.com/news/release-23-10-highlights/
helix-editor/helix#1396
As for me if it complicates configuration and debugging as you said it's not worth it, for now all works
very well, stable - this is more important. But overall some separate binary - LSP proxy is
great idea I think.
I could try to write something myself (no promises). I'd probably write it in go which would make it easier to develop than C used for the plugin. The proxy could also address #38 where on the end towards the servers it could support sockets.
It will be great, with such approach geany-lsp remain without complexeties for debugging, configuration and so on,
and geany-lsp-proxy (let's say :) ) solves sockets issue (for Godot etc.) and multi lsp (I think very useful for python - jedi lsp + ruff lsp for example or pyright lsp + ruff lsp). I heard also that clangd and ccls used by somebody in parallel. It will be great addition to Geany.
I've just created this:
https://github.com/techee/lsp-proxy
It seems to work well for jedi used as the primary server and ruff for diagnostic messages. Let me know if there are any problems.
@techee Fantastic ! ) I will check it. Thanks.
@techee Tested default jedi-language-server and ruff server - works very well, faster than pylsp with ruff addon, seems the same as if to use ruff server directly. Same with autocompletion of jedi-language-server. Will test more. Thank you for such useful addition.
This is now supported (in a limited way) using https://github.com/techee/lsp-proxy and I don't plan this feature directly in the plugin any more. All related issues should be directed to the lsp-proxy project.
Closing.