Closed ghost closed 5 years ago
That's a problem that should probably be fixed in vim-lsp; it should correctly follow the LSP spec, instead of servers having to work around it.
But other language servers are implemented like that, such as https://github.com/sourcegraph/javascript-typescript-langserver and https://github.com/rust-lang/rls .
Maybe they are, but just because other servers don't respect the LSP doesn't mean that other servers should, and the spec is clear:
ClientCapabilities now define capabilities for dynamic registration, workspace and text document features the client supports. The experimental can be used to pass experimental capabilities under development. For future compatibility a ClientCapabilities object literal can have more properties set than currently defined. Servers receiving a ClientCapabilities object literal with unknown properties should ignore these properties. A missing property should be interpreted as an absence of the capability. If a missing property normally defines sub properties, all missing sub properties should be interpreted as an absence of the corresponding capability.
On top of that, fixing vim-lsp means fixing a single client, while introducing workarounds in servers mean possibly having to change more servers than just DLS if other servers correctly implement the spec.
I don't know anything about vimscript, but this code seems to handle capabilities: https://github.com/prabirshrestha/vim-lsp/blob/master/autoload/lsp.vim#L408-L412 It should only be a matter of adding vim-lsp's capabilities in there I think.
OK, I close this PR and try to commit on vim-lsp. Thanks.
When using dls with vim-lsp, I noticed that there are some functions which does not work.
After some examining, I found the cause is that a message from vim-lsp in initialization does not include capabilities parameter, and other most language servers work well because they ignore capabilities parameter from client.
So I propose ignoring the parameters. This fix works fine for me at least.