fix(treesitter): more distinctive highlight for EditQuery captures
Problem: EditQuery shows captures in the source buffer using the Title
highlight group, which could be too similar to Normal.
Solution: Use a virtual text diagnostic highlight group: they are
displayed in a similar manner to the query captures so we can assume
that the color scheme should have appropriate styling applied to make
them visible.
Problem:
`vim.json.decode()` could not parse JSONC (JSON with Comments)
extension, which is commonly used in configuration files.
Solution:
Introduce an `skip_comments` option, which is disabled by default. When
enabled, allows JavaScript-style comments within JSON data.
Problem:
Escaping logic for {subject} in ex cmd `:help {subject}` is done in a
messy 200+ lines C function which is hard to maintain and improve.
Solution:
Rewrite in Lua. Use `string.gsub()` instead of looping over characters
to improve clarity and add many more tests to be able to confidently
improve current code later on.
Problem: cterm field in Dict(highlight) is declared as Union(Integer, String)
but it actually expects a Dict(highlight_cterm).
Solution: change cterm type to DictAs(highlight__cterm) and simplify the
handling in dict2hlattrs since type validation and empty array compat are
already handled by api_dict_to_keydict.
In particular, also mention the difference between the regex atom \k and
what Vim considers for a word character.
closes: vim/vim#186889e456e52df
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
After eaacdc9, complete with emmylua_ls error with:
runtime/lua/vim/lsp/completion.lua:586: attempt to get length of field
'items' (a nil value)
Solution:
Result can be CompletionItem[] according the spec:
> If a `CompletionItem[]` is provided, it is interpreted to be complete,
> so it is the same as `{ isIncomplete: false, items }`
Problem:
Empty response affects server start boundary computed before.
Solution:
Ignore empty responses. This is mostly micro-optimization that avoids
extending existing results with empty responses.
Problem: Code lenses currently display as virtual text on the same line
and after the relevant item. While the spec does not say how lenses
should be rendered, above the line is most typical. For longer lines,
lenses rendered as virtual text can run off the side of the screen.
Solution: Display lenses as virtual lines above the text.
Closes https://github.com/neovim/neovim/issues/33923
Co-authored-by: Yi Ming <ofseed@foxmail.com>
Problem: The following strchar functions have incorrect types:
strcharlen() - Currently any. Always returns an integer, including on
error
strcharpart() - The skipcc annotation does not specify that 0 and 1 are
valid. These inputs are required for vimscript usage. The current
return type is any, even though the function returns an empty string
on error
strchars() - The skipcc annotation does not specify that 0 and 1 are
valid
Solution: Update the problem types.
Problem: In eval.lua, setcharsearch() has an incorrect param type,
causing Lua_Ls to display an error when a valid table is passed.
While getcharsearch correctly states that it returns a table, the type
is non-specific about the contents.
Solution: Update eval.lua with the correct types.
The auto-refresh has a bit of a delay so it can happen that when a user
runs `codelens.run` it operates on an outdated state and either
does nothing, or fails.
This changes the logic for `.run` to always fetch the current lenses
before (optional) prompt and execution.
See discussion in https://github.com/neovim/neovim/pull/37689#discussion_r2764235931
This could potentially be optimized to first check if there's local
state with a version that matches the current buf-version, but in my
testing re-fetching them always was quickly enough that `run` still
feels instant and doing it this way simplifies the logic.
Side effect of the change is that `.run` also works if codelens aren't
enabled - for power users who know what the codelens would show that can
be useful.
Problem: Unlike `nvim_keymap_set`, `vim.keymap.set` uses the non-negated
`remap` instead of `:set`'s `noremap`, but the documentation for this
got lost sometime before Nvim 0.10.
Solution: Restore the lost documentation and make it more explicit.
Problem: UI2 does not implement the msg_show event msg_id parameter.
Solution: Store message IDs currently shown in the cmd/msg buffers.
Set extmarks spanning the message which are used to replace
a still visible message when a new message with the same ID
is received.
From the LSP Spec:
> There are two uses cases where it can be beneficial to only compute
> semantic tokens for a visible range:
>
> - for faster rendering of the tokens in the user interface when a user
> opens a file. In this use case, servers should also implement the
> textDocument/semanticTokens/full request as well to allow for flicker
> free scrolling and semantic coloring of a minimap.
> - if computing semantic tokens for a full document is too expensive,
> servers can only provide a range call. In this case, the client might
> not render a minimap correctly or might even decide to not show any
> semantic tokens at all.
This commit unifies the usage of range and full/delta requests as
recommended by the LSP spec and aligns neovim with the way other LSP
clients use these request types for semantic tokens.
When a server supports range requests, neovim will simultaneously send a
range request and a full/delta request when first opening a file, and
will continue to issue range requests until a full response is
processed. At that point, range requests cease and full (or delta)
requests are used going forward. The range request should allow servers
to return a result faster for quicker highlighting of the file while it
works on the potentially more expensive full result. If a server decides
the full result is too expensive, it can just error out that request,
and neovim will continue to use range requests.
This commit also fixes and cleans up some other things:
- gen_lsp: registrationMethod or registrationOptions imply dynamic
registration support
- move autocmd creation/deletion to on_attach/on_detach
- debounce requests due to server refresh notifications
- fix off by one issue in tokens_to_ranges() iteration
Problem:
`Client.on_exit` runs `Client._on_detach` and the client removal logic
within two separate `vim.schedule` sequentially. However, since
`Client._on_detach` executes `LspNotify` inside `vim.schedule`, this
causes `LspNotify` to be executed after the client removal, which is
scheduled first. At that point, a valid `Client` can no longer be
retrieved within the autocmd callback.
Solution:
Put the client deletion inside the `vim.schedule` call.
Problem:
Temporary files from /tmp/ and /private/ paths clutter :oldfiles list.
Additionally, the documented Windows default (rA:,rB:) was never applied
due to a missing platform condition.
Solution:
Drop platform-specific shada differences and default to excluding
/tmp/ and /private/ paths.
Problem: The wildmenu is hidden behind the dialog window with "list" in 'wildmode'.
Global ('laststatus' set to 3) statusline is hidden behind the
pager window.
Solution: Check wildmenumode() to adjust the dialog position when necessary.
Ensure pager is positioned above the global statusline with 'laststus' set to 3.
Problem: Scheduled callbacks reference potentially outdated window
handles e.g. after switching tabpage.
Solution: Use ext.wins which stores the updated window handles.
Problem:
Using vim.defer_fn() just before Nvim exit leaks luv handles.
Solution:
Make vim.schedule() return an error message if scheduling failed.
Make vim.defer_fn() close timer if vim.schedule() failed.
Problem:
`on_list` is supposed to replace the default list-handler. With the current order of these `if` statements `on_list` won't be called if `loclist` is true.
Solution:
Change the order of the relevant blocks.
Previously, adjust_start_col returned nil when completion items had
different start position from lsp textEdit range
This caused the completion to fall back to \k*$ which ignores the
non-keyword characters
Changes:
- adjust_start_col: now returns the minimum start postion among all
items instead of nil
- _lsp_to_complete_items - normalizes the items by adding the gap between
current and minimum start
Fixes: https://github.com/neovim/neovim/issues/37441
Although powerful -- especially with chained modifiers --, the
readability (and therefore maintainability) of `fnamemodify()` and its
modifiers is often worse than a function name, giving less context and
having to rely on `:h filename-modifiers`. However, it is used plenty in
the Lua stdlib:
- 16x for the basename: `fnamemodify(path, ':t')`
- 7x for the parents: `fnamemodify(path, ':h')`
- 7x for the stem (filename w/o extension): `fnamemodify(path, ':r')`
- 6x for the absolute path: `fnamemodify(path, ':p')`
- 2x for the suffix: `fnamemodify(path, ':e')`
- 2x relative to the home directory: `fnamemodify(path, ':~')`
- 1x relative to the cwd: `fnamemodify(path, ':.')`
The `fs` module in the stdlib provides a cleaner interface for most of
these path operations: `vim.fs.basename` instead of `':t'`,
`vim.fs.dirname` instead of `':h'`, `vim.fs.abspath` instead of `':p'`.
This commit refactors the runtime to use these instead of fnamemodify.
Not all fnamemodify calls are removed; some have intrinsic differences
in behavior with the `vim.fs` replacement or do not yet have a
replacement in the Lua module, i.e. `:~`, `:.`, `:e` and `:r`.
Problem:
Two cases lsp.enable() won't work in the first FileType event
1. lsp.enable luals inside FileType or ftplugin/lua.lua, then:
```
nvim a.lua
```
2. lsp.enable luals inside FileType or ftplugin/lua.lua, then:
```
nvim -> :edit a.lua -> :mksession! | restart +qa! so Session.vim
```
Solution:
Currently `v:vim_did_enter` is used to detected two cases:
1. "maunally enabled" (lsp.enable() or `:lsp enable`)
2. "inside FileType event"
To detect 2. correctly we use did_filetype().
Problem:
If `vim.lsp.enable()` fails with an error, either because `'*'` is one
of the provided names or because there is an error in a config,
`vim.lsp.enable()` will still have side-effects:
- All names before the one that encountered an error will still be added
to `lsp._enabled_configs`, but the autocommand will not get added or
run.
- Any name which makes `vim.lsp.config[name]` error will be added to
`lsp._enabled_configs`, causing all future calls to `vim.lsp.enable()`
to fail. This will also break `:che vim.lsp`.
Solution:
- Check all names for errors before modifying `lsp._enabled_configs`.
- Check `vim.lsp.config[name]` does not raise an error before enabling
the name.
Problem: In float mode, vim.schedule() may run before filetype is set,
so winbar is not shown.
Solution: Use FileType autocmd to ensure winbar is set after filetype.
Also use type=Bug in URL.
