Dynamic capabilities were introduced in neovim with commit ddd92a7.
With dynamic registration of LSP capabilities, a client's `server_capabilities`
is no longer a sufficient indicator to see if a server supports a feature. We
instead need to use `client.supports_method(<method>)` which considers both
the dynamic capabilities and static `server_capabilities`.
Drop nvim-lightbulb and just add the needed functionality. This also
fixes a minor bug where the code action detection was incorrectly
being done under codeLensProvider instead of codeActionProvider.
Define functions in a consistent way through out. We like the pattern
`local function_name = function()` instead of `local function_name()`
for defining functions.
Some language servers like HLS take longer to attach and if we exit
soon before LSP attach had a chance to finish (may be?), server
capabilities field does not seem to be valid in client object and
we get the below error. Check if it valid first.
Error detected while processing LspDetach Autocommands for "*":
Error executing lua callback: /home/core/.config/nvim/lua/lsp.lua:215: attempt to index field 'server_capabilities' (a nil value)
stack traceback:
/home/core/.config/nvim/lua/lsp.lua:215: in function </home/core/.config/nvim/lua/lsp.lua:209>
[C]: in function 'nvim_exec_autocmds'
/usr/local/share/nvim/runtime/lua/vim/lsp.lua:1140: in function </usr/local/share/nvim/runtime/lua/vim/lsp.lua:1139>
Error executing lua callback: /home/core/.config/nvim/lua/lsp.lua:215: attempt to index field 'server_capabilities' (a nil value)
stack traceback:
/home/core/.config/nvim/lua/lsp.lua:215: in function </home/core/.config/nvim/lua/lsp.lua:209>
[C]: in function 'nvim_exec_autocmds'
/usr/local/share/nvim/runtime/lua/vim/lsp.lua:1140: in function </usr/local/share/nvim/runtime/lua/vim/lsp.lua:1139>
Disable logging completely. The set_log_level call needs to be at the
top level else some log message related to startup still gets logged
if the call is done in on_attach.
Use the new vim.lsp.start API and LspAttach/Detach auto commands.
Drop nvim-lspconfig in the process.
LSP server specific configuration has been taken from nvim-lspconfig.
We do not use any of the other features provided by rust-tools and
only ever needed the inlay hints. Now that there is a plugin for
that which also allows us to use inlay hints for other languages
use that.
There are two options
https://github.com/lvimuser/lsp-inlayhints.nvimhttps://github.com/simrat39/inlay-hints.nvim
The second one is from the rust-tools author himself but we could
not get that to work.
The plugin is in maintenance mode and typescript.nvim does not support
inlay hints. We already use eslint language server and extra commands
provided by lsp-ts-utils/typescript.nvim is something we have never
used. Just drop it.
vim.lsp.buf.formatting function is deprecated and now replaces all the
below three functions with vim.lsp.buf.format.
- vim.lsp.buf.formatting
- vim.lsp.buf.formatting_sync
- vim.lsp.buf.formatting_seq_sync
client.resolved_capabilities is no longer used. One must now access
client.server_capabilities which matches the same structure as the
protocol.
https://microsoft.github.io/language-server-protocol/specification
See neovim commit c618b31.
We had added lua-language-server thinking it would be helpful for
Wireplumber development, but, due to the nature of lua and server
itself, the experience is utter crap in comparison to using LSP in
other languages.
See the below issue
https://github.com/jose-elias-alvarez/nvim-lsp-ts-utils/issues/87
We went with null-ls because we wanted formatting with prettier. Also
null-ls was recommended by nvim-lsp-ts-utils.
The advantage of null-ls is it provides formatting and diagnostics
together in one package.
However, we will get prettier by another means and for linting switch to
nvim-lint.
Sanchayan Maity