Add new capabilities

[fspv]

Hi! This library seems to be not supporting the new capabilities, such as inlayHint. As a result arduino LSP (which depends on it) doesn't work with the newer IDE versions. See description of the problem here arduino/arduino-language-server#187

Is it possible to update the capabilities definition with all the new available capabilities?

[fspv]

I tried to add missing fields myself, but it seems like a huge change will be required to support 3.17 protocol version (just grep for @since 3.17.0 here if you want to see the scale of the problem yourself).

At the same time, it seems like everything needed is already implemented and well-supported in gopls
https://github.com/golang/tools/tree/2d104ec5d29fd2c2156ce4e7f1ca9c0258bab055/gopls/internal/protocol
However, all of that is located in the internal go package hence it can't be used from the other go module.

So there are two paths we can take here:

• Modify this package to support all the new methods
• Create a completely separate package and try to reuse gopls tooling to create a new server

Ideally will be nice if the author of the package shows up and provides some guidance or support on the first solution. Otherwise, I believe the new package way will be much easier to implement.

[cmaglie]

Hi @fspv, thanks for your interest in this package.

I've made this package for the Arduino LS, and yes, keeping up with the upstream LSP specification is a work on his own.
I looked into the gopls package some time ago, but the authors did make it internal, if we would like to use it we may face with a package not designed for external usage and we may also face breaking changes in the future (it may be better or worse than maintaining our package, who knows...).

Said that, IMHO the best way forward is to implement the minimum subset of LSP 3.17 to support neovim in this library. WDYT?

Another thing that puzzles me is that the LSP protocol is designed in a way that the client and the server can negotiate the capabilities https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocumentClientCapabilities for example if the optional inlayHint field is missing the LSP client should not send those requests. At least this is my understanding of the protocol...

[fspv]

Hi @cmaglie! Sorry, took quite a while to respond, because I lost context on this and it took some time to figure it out again.

This is the neovim code that constructs the default capabilities to be sent to the server: https://github.com/neovim/neovim/blob/v0.10.0/runtime/lua/vim/lsp/protocol.lua#L635-L656

There is no way to make inlayHint key in the dictionary disappear. You can overwrite it with some nonsense, but it will still be passed to the server and will result in a deserialization error.

I think your point is valid, that the client must negotiate the supported features with the server, however, I'm not sure if it includes the client not sending its capabilities in the first place. If this is the case, then it seems like a bug on the neovim side. However, I'm leaning towards thinking that the server must accept whatever it's been provided by the client and then try to match the client's capabilities with what it supports. So extra capabilities on the client shouldn't be a problem.

So maybe a solution here will be to relax the JSON parsing constraints and just ignore the unknown keys. I'm not sure if the library used here supports it though.

Or if we are sure this is a neovim bug, then we can report it its repo, I think we have a solid case here for adding an option to stop sending the inlayHint field.

[fspv]

@leoverde2 in this thread says they fixed the problem with a small change

[mike-lloyd03]

I opened a PR to implement the change recommended in the arduino-language-server issue. I tested it locally and the LSP appears to work as expected under nvim 10.0.