Support multiple language servers per filetype #17
Comments
|
Contextual language recognition would be practically impossible, but a comment-based approach could be feasible |
|
This would enable using |
|
Or could we make a "proxy" language server, which kak-lsp talks to, and that interacts with potentially multiple language servers? |
|
The proxy solution has benefits that it potentially could be re-used outside of kak-lsp. We need to draft how is it supposed to behave, i.e. merge strategies for various responses etc. |
|
I know this issue is a little stale, but I just found a project that proxies to multiple language servers. Has anyone tried this? |
|
As far as I can tell, that project's purpose is to create a websocket interface for language servers that don't support one themselves. |
I think it's still a good idea, especially considering that VSCode already supports that (it can display diagnostics from multiple language servers, for example).
Right, it looks like this project only forwards requests to one language server. We need something that forwards one request to (potentially) multiple servers. I like to call it Merging strategies can get a bit complicated, but if we start by showing the union of all diagnostics (and take everything else only from a "primary" language server) that sounds easy and could already be good enough? |
Wouldn't that imply having to provide the same set of configurations from an individual language server to this "sink" language server as well? This feels a little redundant. Also, this strategy would leave the responsibility of managing processes up to the sink server, which is not always desired. I think this would only be useful for If we consider a client-level approach, what are the current blockers that make supporting multiple language servers unviable in |
|
On Mon, Nov 14, 2022 at 11:25:23AM -0800, Gabriel Sanches wrote:
If we consider a client-level approach, what are the current blockers that make supporting multiple language servers unviable in `kak-lsp`?
none that I know of
|
|
Adding my usecase: I run |
|
looks like someone implemented the proxy language server, see https://github.com/messense/multi-lsp-proxy |
|
Anyone here willing to try #686? It shouldn't be too hard to set up a multi-language config (there's an example in the PR description). |
Today, kak-lsp.toml maps language IDs to language servers. Each filetype is assigned one language ID, which in turn is assigned one server. For example, [language.typescriptreact] filetypes = ["javascript", "typescript"] command = "my-language-server" assigns filetypes "javascript" and "typescript" to language ID "typescriptreact" and one language server. Allow multiple language servers per filetype. This looks like [language_server.my-language-server1] filetypes = ["javascript", "typescript"] [language_server.my-language-server2] filetypes = ["javascript", "typescript"] The`my-language-server1` part is no longer the language ID (which is required by LSP) but the unique (but arbitrary) server name. The language ID defaults to the filetype; add new top-level `language_ids` for cases where they do not match. For example, [language_ids] javascript = "javascriptreact" typescript = "typescriptreact" The old configuration syntax is still supported for now (but not tested much). Closes kakoune-lsp#17
Today, kak-lsp.toml maps language IDs to language servers. Each filetype is assigned one language ID, which in turn is assigned one server. For example, [language.typescriptreact] filetypes = ["javascript", "typescript"] command = "my-language-server" assigns filetypes "javascript" and "typescript" to language ID "typescriptreact" and one language server. Allow multiple language servers per filetype. This looks like [language_server.my-language-server1] filetypes = ["javascript", "typescript"] [language_server.my-language-server2] filetypes = ["javascript", "typescript"] The`my-language-server1` part is no longer the language ID (which is required by LSP) but the unique (but arbitrary) server name. The language ID defaults to the filetype; add new top-level `language_ids` for cases where they do not match. For example, [language_ids] javascript = "javascriptreact" typescript = "typescriptreact" The old configuration syntax is still supported for now (but not tested much). Co-authored-by: Johannes Altmanninger <aclopte@gmail.com> Closes kakoune-lsp#17
Today, kak-lsp.toml maps language IDs to language servers. Each filetype is assigned one language ID, which in turn is assigned one server. For example, [language.typescriptreact] filetypes = ["javascript", "typescript"] command = "my-language-server" assigns filetypes "javascript" and "typescript" to language ID "typescriptreact" and one language server. Allow multiple language servers per filetype. This looks like [language_server.my-language-server1] filetypes = ["javascript", "typescript"] [language_server.my-language-server2] filetypes = ["javascript", "typescript"] The`my-language-server1` part is no longer the language ID (which is required by LSP) but the unique (but arbitrary) server name. The language ID defaults to the filetype; add new top-level `language_ids` for cases where they do not match. For example, [language_ids] javascript = "javascriptreact" typescript = "typescriptreact" The old configuration syntax is still supported for now (but not tested much). Co-authored-by: Johannes Altmanninger <aclopte@gmail.com> Closes #17
Use case: for javascript files I want diagnostics from both eslint and flow language servers.
The text was updated successfully, but these errors were encountered: