* Also fix newly found type mismatch.
* Note that it generates new warnings about using @private client
methods. A proper fix would be to revamp the lsp client documentation
altogether.
Problem:
Some built-in ftplugins set omnifunc/tagfunc/formatexpr which causes
lsp.lua:set_defaults() to skip setup of defaults for those filetypes.
For example the C++ ftplugin has:
omnifunc=ccomplete#Complete
Last set from /usr/share/nvim/runtime/ftplugin/c.vim line 30
so the changes done in #95c65a6b221fe6e1cf91e8322e7d7571dc511a71
will always be skipped for C++ files.
Solution:
Overwrite omnifunc/tagfunc/formatexpr options that were set by stock
ftplugin.
Fixes#21001
feat(lsp)!: change semantic token highlighting
Change the default highlights used, and add more highlights per token.
Add an LspTokenUpdate event and a highlight_token function.
:Inspect now shows any highlights applied by token highlighting rules,
default or user-defined.
BREAKING CHANGE: change the default highlight groups used by semantic
token highlighting.
This small changes just ensures that if you're using `convert_input_to_markdown_lines`
without `contents` you don't get a warning (when using something like neodev) that
there is an expected second param, since it can be nil.
Small, but I was getting warnings about my usage of
`vim.lsp.buf_notify(bufnr, method, {example = example})` since the docs
say that `params` must be a string, however this can really be anything
when it's passed to `rpc.notify` since we just end up calling
`vim.json.encode(payload)` on it. This fixes the docs in those two
places and regenerates them.
Problem:
No easy way to position a LSP hover window relative to mouse.
Solution:
Introduce another option to the `relative` key in `nvim_open_win()`.
With this PR it should be possible to override the handler and do something
similar to this https://github.com/neovim/neovim/pull/19481#issuecomment-1193248674
to have hover information displayed from the mouse.
Test case:
```lua
local util = require('vim.lsp.util')
local function make_position_param(window, offset_encoding)
window = window or 0
local buf = vim.api.nvim_win_get_buf(window)
local row, col
local mouse = vim.fn.getmousepos()
row = mouse.line
col = mouse.column
offset_encoding = offset_encoding or util._get_offset_encoding(buf)
row = row - 1
local line = vim.api.nvim_buf_get_lines(buf, row, row + 1, true)[1]
if not line then
return { line = 0, character = 0 }
end
if #line < col then
return { line = 0, character = 0 }
end
col = util._str_utfindex_enc(line, col, offset_encoding)
return { line = row, character = col }
end
local make_params = function(window, offset_encoding)
window = window or 0
local buf = vim.api.nvim_win_get_buf(window)
offset_encoding = offset_encoding or util._get_offset_encoding(buf)
return {
textDocument = util.make_text_document_params(buf),
position = make_position_param(window, offset_encoding),
}
end
local hover_timer = nil
vim.o.mousemoveevent = true
vim.keymap.set({ '', 'i' }, '<MouseMove>', function()
if hover_timer then
hover_timer:close()
end
hover_timer = vim.defer_fn(function()
hover_timer = nil
local params = make_params()
vim.lsp.buf_request(
0,
'textDocument/hover',
params,
vim.lsp.with(vim.lsp.handlers.hover, {
silent = true,
focusable = false,
relative = 'mouse',
})
)
end, 500)
return '<MouseMove>'
end, { expr = true })
```
Currently once you retrieve the lenses you're pretty much stuck with
them as saving new lenses is additive.
Adding a dedicated method to reset lenses allows users to toggle lenses
on/off which can be useful for language servers where they are noisy or
expensive and you only want to see them temporary.
Apply semantic token modifiers as separate extmarks with corresponding
highlight groups (e.g., `@readonly`). This is a low-effort PR to enable
the most common use cases (applying, e.g., italics or backgrounds on top
of type highlights; language-specific fallbacks like `@global.lua` are
also available). This can be replaced by more complicated selector-style
themes later on.
* credit to @smolck and @theHamsta for their contributions in laying the
groundwork for this feature and for their work on some of the helper
utility functions and tests
Problem:
The {foo} parameters listed in `:help api` and similar generated docs,
are intended to be a "list" but they aren't prefixed with a list symbol.
This prevents parsers from understanding the list, which forces
generators like `gen_help_html.lua` to use hard-wrapped/preformatted
layout instead of a soft-wrapped "flow" layout.
Solution:
Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
This starts a soft phase-out of `buf_request`.
`buf_request` is quite error prone:
- Positional `params` depend on the client because of the
`offset_encoding`. Currently if there is one client using UTF-8 offset
encoding and another using UTF-16, the positions in the request are
wrong for one of the clients. To solve this the params would need to
be created per client instead of once for all of them.
- `handler` is called *per* client but many users of it assume it is
only called once.
This can lead to a "select n + 1"
kind of problem, where the handler makes another call to `buf_request`,
multiplying the amount of requests.
(There are in fact still some places where this happens in core)
Or it leads to erratic behavior if called multiple times (E.g. the
quicklist list flickering & being overwritten)
(See hover or references implementation)
`buf_request_all` returns an aggregate of the responses which is more
sensible as it avoids this problem.
For off-spec extensions it also has the problem that it sends requests to
clients which cannot handle a given request.
Given that `buf_request` is in use by a lot of plugins this starts a
soft-phase out. Planned Steps:
- Remove from docs
- Provide an alternative, either `buf_request_all`, maybe with
extensions (params being a function), or an entirely new method.
- Mark as deprecated in 0.9
- Remove in 0.10
To note:
- `buf_request_all` currently isn't ideal either because it suffers from
the `params` problem as well.
- This implies that the `vim.lsp.with` pattern will die, because the
global handlers as they are don't fit a multi-client model, as most of
the time an aggregate is needed.
