> The Language Server protocol is used between a tool (the client) and a language smartness provider (the server) to integrate features like auto complete, go to definition, find all references and alike into the tool
In LSP terms, these are called "capabilities". The relevant section in the LSP spec is here [1].
There's some variation across editors in exactly how the config works - or, at least, part of it. Some config is done in native files that form part of the plugin. Those are largely editor-specific. The protocol itself defines messages for the server to indicate which facilities it supports. Those are (mostly) editor neutral from my experience thus far (mostly VSCode, a little Emacs).
--
EDIT: added link to capabilities section in the LSP spec.
[1]: https://microsoft.github.io/language-server-protocol/specifi...
The key insight with LSP is that languages are _way_ too different to have that notion of language capabilities. Instead, the LSP defines functionality that the editor wants to use (syntax highlighting, refactoring, autocomplete, etc) and the language server tells the editor what to display.
When you trigger autocomplete in VSCode, the editor has no clue whether it’s autocompleting a method, a class name, or a variable. It’s just telling the language server “hey the user asked for autocomplete in file X, offset Y” and the language server tells the editor what completion options to offer.
And yet the very opposite of this is the source of JetBrains success.