Add support for multiple language servers per language

[Philipp-M]

Adds support for multiple language servers per language.

Language Servers are now configured in a separate table in languages.toml:

[langauge-server.mylang-lsp]
command = "mylang-lsp"
args = ["--stdio"]
config = { provideFormatter = true }

[language-server.efm-lsp-prettier]
command = "efm-langserver"

[language-server.efm-lsp-prettier.config]
documentFormatting = true
languages = { typescript = [ { formatCommand ="prettier --stdin-filepath ${INPUT}", formatStdin = true } ] }

The language server for a language is configured like this (typescript-language-server is configured by default):

[[language]]
name = "typescript"
language-servers = [ { name = "efm-lsp-prettier", only-features = [ "format" ] }, "typescript-language-server" ]

or equivalent:

[[language]]
name = "typescript"
language-servers = [ { name = "typescript-language-server", except-features = [ "format" ] }, "efm-lsp-prettier" ]

Each requested LSP feature is priorized in the order of the language-servers array.
For example the first goto-definition supported language server (in this case typescript-language-server) will be taken for the relevant LSP request (command goto_definition).

If no except-features or only-features is given all features for the language server are enabled, as long as the language server supports these. If it doesn't the next language server which supports the feature is tried.

The list of supported features are:

• format
• goto-definition
• goto-declaration
• goto-type-definition
• goto-reference
• goto-implementation
• signature-help
• hover
• document-highlight
• completion
• code-action
• workspace-command
• document-symbols
• workspace-symbols
• diagnostics
• rename-symbol
• inlay-hints

Another side-effect/difference that comes with this PR, is that only one language server instance is started if different languages use the same language server.

[the-mikedavis]

It might be good to survey how other LSP clients handle multiple LSPs. I suspect that the features should be configurable so you can choose which language server configuration is used to format or request signature-help or autocompletion. Requesting auto-complete from multiple language servers and merging the values could be disirable as well as code actions and diagnostics.

[andreytkachenko]

My opinion

1. I think we need to create completion source manager where be registered different sources based on some trait(even from plugins). And LSPs should be entries in that list as well as other with priority.
2. About conflicting functionality, I think easiest way would be to perform actions in order they appear in configuration file. But better is to be able setup preferred server for some actions like formatting, etc.

[Philipp-M]

I think we need to create completion source manager where be registered different sources based on some trait(even from plugins). And LSPs should be entries in that list as well as other with priority.

Yes, I also think there needs to be something like that, currently one completion request future fills the completion menu. I'm pretty sure in the near future there will be multiple completion sources (like file-path completion, which is useful most of the time I think).

Same applies of course for code-actions and diagnostics.

Maybe this should be done before this PR?

Btw. I've tested this PR so far with typescript-language-server and eslint (for diagnostics) via efm-langserver (in this order) which seems to be working quite well already.

[the-mikedavis]

There is #1015 and #2403 along those lines. I don't think anyone is working on file-path completion at the moment but it should be simpler to implement than #2403 and could help with multiple completion sources as you say.

[Philipp-M]

An update:

Merging of completion results, code-action and symbols in the symbol picker(s) are working now.

I have slightly refactored the UI components Menu, Completion and (File)Picker to be able to extend options/items after the respective component has been created. I've also added support to call score without resetting the cursor inside the menu or picker (relevant, when an LSP takes some time, while already selecting options). It may make sense to put these commits (
d97da46, a376e02 and a705b70) into its/their own PR.

Merging works like this currently:

spawn all lsp-request futures,

and then collect them in a loop, the first finished future, creates the menu/picker/etc. and the next futures extend it.

This could potentially mean, that if the menu/picker etc. was closed in the meantime that a new menu/picker is spawned, if one of the LSP takes too long for a request. This could be tackled with Mutexes (see in code_action, here: 5040679#diff-abe37ebb421b375471daa248c8de6541335e61dd3dfc93ee999eb108876e5837R213)

I'm not sure if it makes sense to refactor the way the ui collects its data further (e.g. via streams or something), it may get too complex this way I guess...

[Philipp-M]

Another thing I've noticed, a few other editors have separated LSPs from the languages (like neovim).

This may make sense, if an LSP should be used for multiple languages at once (e.g. efm-langserver), in the case of efm-langserver, it would mean less unnecessary spawned LSPs, but I'm not sure if it's worth the effort, to support that as well.
I'm not sure if there's a case, where it is relevant that the same LSP instance is used for multiple languages (e.g. html/css/js).
If that's the case, I think we should support this.

E.g. extend languages.toml like:

[[language-server]]
name="efm-frontend" # could be used as unique id
command="efm-langserver"
config = {..}

# ...

[[language]]
name = "typescript"
language-servers = [
    {
        command = "typescript-language-server",
        args = ["--stdio"],
        language-id = "javascript"
    },
    "efm-frontend"
]

[Philipp-M]

I think I got a little bit ahead of myself...

I have now implemented pretty much everything I think is necessary to support multiple language servers.

This includes the change suggested in the previous comment, with the exception, that every language server is now configured in a separate table language-server (for simplicity and consistency).

I think the rest is hopefully documented well enough in adding_languages.md.

I will update the PR message if all is good

[Philipp-M]

Is there anything I can do, that makes reviewing this PR easier? Like splitting not directly related parts into its own PR? (Since keeping this up-to-date with master is quite some work...)

[sudormrfbin]

Splitting the PR into multiple smaller ones (even dependent ones, where one PR depends on another to be merged first) would definitely make reviewing easier. Some PRs cannot do this and that's fine, but where possible breaking them down is always better.

[JulianH99]

When will this be on release so that it appears on scoop as well?

[dead10ck]

When will this be on release so that it appears on scoop as well?

We don't maintain the scoop package, so you'll have to ask whoever does.

[MarkStruik]

When will this be on release so that it appears on scoop as well?

We don't maintain the scoop package, so you'll have to ask whoever does.

Fair enough but I would imagine they do not update it until there is a new official release. Now if I look at past releases it might suggest end of August?

[the-mikedavis]

Yep, we're working on a release that will include this and the other changes in master. We try to release every few months (see the faq) but we don't commit to firm timelines / ETAs.

[leona]

I know this is closed, but maybe someone has an answer. Is it possible to append a language server, rather than replace the current ones? If wanted one for every language (copilot) for example, that would be a bit tedious. Being able to just add a language server rather than overwrite would be great.

[Philipp-M]

Your proposal makes sense, and I think I've thought about something like that (pretty much the use-case you've presented).

You could open an issue with a design of the configuration you think makes sense (when there isn't yet an issue with that, haven't searched for that...).

[pascalkuthe]

#9318 will actually allow that

[zetashift]

Any update on this?

Multiple language servers per language has already been merged and is available (for several releases now). Is something not working in your config? If so, I'd recommend making a new issue for it.

It's on these tiny things that are redundant and upvoted a lot, that you guys should work on

It's OSS, people should work on whatever they like.

[zetashift]

Read again: one common LSP for all languages

I still recommend you make a separate issue(or even better a discussion) describing what you're expecting. Your request is off-topic for this PR, since it's a completely separate part of the language server protocol compared to your "common LSP for all languages".

Even re-reading it, I'm not sure what you're getting it, but it has no place in this PR.

[Rudxain]

Read again: one common LSP for all languages

Do you mean a global default LSP? Like, instead of manually setting the name for every language, we specify it once and the editor will invoke it regardless of the file-type that is opened?

That could be useful for LSPs such as this one, as mentioned here

[VuiMuich]

As mentioned before, you should open an separate issue or discussion for this feature wish.

Discussion on a PR should be about implementation details, scope and features or bugs before merge. Post-merge it comments should be kept to the necessary minimum of referencing for other PRs or issues, to keep the noise low for people who got subscribed to a PR over time.

[Philipp-M]

This is a long-merged PR, you're notifying a lot of people with something that should definitely be a separate issue, as it is an additional feature, that is somewhat orthogonal to this PR, and well this PR is merged, so it just doesn't make sense to discuss this here, as we can't merge it again in a different state...

And if you care so much about it, just implement it, don't expect other people to do this in their free-time.

[the-mikedavis]

Necrobumping is poor form but at this point I'm pretty sure you're just trolling / rage baiting. Knock it off.