The spacing fix drew attention to a couple of places that were using
incorrect formatting such as the key listing for `nvim_open_win`, so
those were fixed too.
This is mostly motivated by https://github.com/neovim/neovim/issues/12326
Client side commands might need to access the original request
parameters.
Currently this is already possible by using closures with
`vim.lsp.buf_request`, but the global handlers so far couldn't access
the request parameters.
This generalizes diagnostic handling outside of just the scope of LSP.
LSP clients are now a specific case of a diagnostic producer, but the
diagnostic subsystem is decoupled from the LSP subsystem (or will be,
eventually).
More discussion at [1].
[1]: https://github.com/neovim/neovim/pull/15585
Previously, the handler signature was:
function(err, method, params, client_id, bufnr, config)
In order to better support external plugins that wish to extend the
protocol, there is other information which would be advantageous to
forward to the client, such as the original params of the request that
generated the callback.
In order to do this, we would need to break symmetry of the handlers, to
add an additional "params" as the 7th argument.
Instead, this PR changes the signature of the handlers to:
function(err, result, ctx, config)
where ctx (the context) includes params, client_id, and bufnr. This also leaves
flexibility for future use-cases.
BREAKING_CHANGE: changes the signature of the built-in client handlers, requiring
updating handler calls
The official developer documentation in in :h dev-lua-doc specifies to
use "--@" for special/magic tokens. However, this format is not
consistent with EmmyLua notation (used by some Lua language servers) nor
with the C version of the magic docstring tokens which use three comment
characters.
Further, the code base is currently split between usage of "--@",
"---@", and "--- @". In an effort to remain consistent, change all Lua
magic tokens to use "---@" and update the developer documentation
accordingly.
Add a new function to redraw diagnostics from the current diagnostic
cache, without receiving a "publishDiagnostics" message from the server.
This is already being done in two places in the Lua stdlib, so this
function unifies that functionality in addition to providing it to third
party plugins.
An example use case for this could be a command or key-binding for
toggling diagnostics virtual text. The virtual text configuration option
can be toggled using `vim.lsp.with` followed by
`vim.lsp.diagnostic.redraw()` to immediately redraw the diagnostics
with the updated setting.
The handlers for textDocument/references, textDocument/documentSymbol,
and workspace/symbol open their results in the quickfix list by default
and are not configurable. They are also incompatible with `vim.lsp.with`
as they do not accept a configuration parameter.
Add a `config` parameter to the handler for these three messages which
allows them to be configured with `vim.lsp.with`. Additionally, add a
new configuration option 'loclist' that, when true, causes these
handlers to open their results in the location list rather than the
quickfix list.
In the documentation for `vim.lsp.util.open_floating_preview`
the opts table keys were prefixed with `--` instead of `---`,
preventing capture by docgen.
With the new implementation added in
https://github.com/neovim/neovim/pull/14079 I think this is now working
well enough to enable it by default.
There are high CPU usage issues popping up now and then and they might
at least partially be related to the full-text sync.
* Allow specifying a languageId for a lsp
For some languages the filetype might not match the languageId the
language server accepts. In these cases the config for the language
server can contain a function which gets the current buffer and filetype
and returns a languageId. When it isn't provided the filetype is used
instead.
Example:
```lua
require'lspconfig'.sourcekit.setup{
get_language_id = function(bufnr, ft)
return 'swift'
end;
}
```
Closes#13093
* lsp: Change to get_language_id
Co-authored-by: Jan Dammshäuser <mail@jandamm.de>
Currently it's not 100% clear that without setting these, using the autocomds
to utilize the `textDocument/documentHighlight` functionality, nothing will
actually be visible since the highlight groups don't have any details. This
just adds in a couple simple extra notes to make sure that's done
