Problem:
"Failed to delete autocmd" error when deleting LspNotify autocmd. #24456
Solution:
Change a few things in the inlay_hint and diagnostic LSP code:
1. Re-introduce the `enabled` flag for the buffer state tables. Previously I was
relying on the presence of an autocmd id in the state table to track whether
inlay_hint / diagnostic was enabled for a buffer. There are two reasons why
this doesn't work well:
- Each time inlay_hint / diagnostic is enabled, we call `nvim_buf_attach` on
the buffer, resulting in multiple `on_reload` or `on_detach` callbacks being
registered.
- Commands like `bwipeout` delete buffer local autocmds, sometimes before our
`on_detach` callbacks have a chance to delete them first. This causes the
- Use module local enabled state for diagnostic as well. bwipeout can race
with on_detach callbacks for deleting autocmds. Error referenced in #24456.
2. Change the `LspDetach` autocmd to run each time (i.e., remove the `once`
flag). Since we're only registering autocmds once per buffer now, we
need to make sure that we set the enabled flag properly each time the LSP
client detaches from the buffer.
- Remove `once` from the LspDetach autocmds for inlay_hint and diagnostic.
We only set up the autocmd once now. Gets removed when buffer is deleted.
3. Have the `LspNotify` handler also refresh the inlay_hint / diagnostics when
receiving the `textDocument/didOpen` event. Before this point, the LSP
backend doesn't have the contents of the buffer, so can't provide inlay hints
or diagnostics.
Downsides of this approach:
* When inlay_hint / diagnostics are disabled on a buffer, it will continue to
receive `LspNotify` events for that buffer. The callback exits early since the
`enabled` flag is false.
Alternatives:
* Can we wrap the call to `nvim_del_autocmd` in `pcall` to swallow any errors
resulting from trying to delete the autocmd?
Fixes#24456
Helped-by: Maria José Solano <majosolano99@gmail.com>
Problem:
Content that has codeblocks with different languages, results in
multiple calls to:
syntax include vim syntax/vim.vim
which raises error:
E403: syntax sync: line continuations pattern specified twice
Before ba8f19ebb6, this was avoided by
using pcall() to ignore the error.
Solution:
Restore the use of pcall() to ignore the error.
We plan to replace this logic with a treesitter approach, so this is
good enough for now.
Fix#24431
* fix(lsp): replace @private with @nodoc for public client functions
To prevent lua-ls warnings in plugins which use the functions.
* fix(lsp): remove duplicate type annotations/class definitions
These annotations became duplicate with https://github.com/neovim/neovim/pull/23750
When adding `workspace/didChangeWorkspaceFolders` support to my [language server](https://github.com/elixir-tools/next-ls), I noticed that when neovim removes a workspace, it sends an empty table (which is serialized to an empty JSON array) for the value in the `added` field.
This does not follow the spec; the `added` table should just be empty.
The following error led me to this discovery. Note the payload includes `"added" => [[]]`:
```
22:46:48.476 [error] LSP Exited.
Last message received: handle_notification %{"jsonrpc" => "2.0", "method" => "workspace/didChangeWorkspaceFolders", "params" => %{"event" => %{"added" => [[]], "removed" => [%{"name" => "/Users/mitchell/src/gen_lsp", "uri" => "file:///Users/mitchell/src/gen_lsp"}]}}}
** (MatchError) no match of right hand side value: {:error, %{"params" => %{"event" => %{"added" => [error: "expected a map"]}}}}
(gen_lsp 0.4.0) lib/gen_lsp.ex:265: anonymous fn/4 in GenLSP.loop/3
(gen_lsp 0.4.0) lib/gen_lsp.ex:292: GenLSP.attempt/3
(stdlib 5.0.2) proc_lib.erl:241: :proc_lib.init_p_do_apply/3
```
In the case you hit this warning in a buffer (like with C++ and clangd),
this message potentially fires over and over again making it difficult
to use the editor at all.
* docs(lua): teach lua2dox how to table
* docs(lua): teach gen_vimdoc.py about local functions
No more need to mark local functions with @private
* docs(lua): mention @nodoc and @meta in dev-lua-doc
* fixup!
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
---------
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem:
Bash language server returns "hover" markdown content that starts with
a code fence and info string of `man` preceded by whitespace, which Nvim
does not render properly.
See 0ee73c53ce/server/src/server.ts (L821C15-L821C15)
```typescript
function getMarkdownContent(documentation: string, language?: string): LSP.MarkupContent {
return {
value: language
? // eslint-disable-next-line prefer-template
['``` ' + language, documentation, '```'].join('\n')
: documentation,
kind: LSP.MarkupKind.Markdown,
}
}
```
For example,
```
``` man
NAME
git - the stupid content tracker
```
```
If I remove the white space, then it is properly formatted.
```
```man instead of ``` man
```
Per CommonMark Spec https://spec.commonmark.org/0.30/#info-string
whitespace is allowed before and after the `info string` which
identifies the language in a codeblock.
> The line with the opening code fence may optionally contain some text
> following the code fence; this is trimmed of leading and trailing
> spaces or tabs and called the [info
> string](https://spec.commonmark.org/0.30/#info-string). If the [info
> string](https://spec.commonmark.org/0.30/#info-string) comes after
> a backtick fence, it may not contain any backtick characters. (The
> reason for this restriction is that otherwise some inline code would
> be incorrectly interpreted as the beginning of a fenced code block.)
Solution:
Adjust stylize_markdown() to allow whitespace before codeblock info.
Problem: `hl_mode` for inlay hints is `combine`, causing bugs like
inlay hints using highlights from the previous character
(#24152, #24068)
Solution: Don't use hl_mode=combine for inlay hints.
Problem:
Showing an error via vim.notify() makes it awkward for callers such as
lsp/handlers.lua to avoid showing redundant errors.
Solution:
Return the message instead of showing it. Let the caller decide whether
and when to show the message.
---
Rejected experiment: move vim.ui.open() to vim.env.open()
Problem:
`vim.ui` is where user-interface "providers" live, which can be
overridden. It would also be useful to have a "providers" namespace for
platform-specific features such as "open", clipboard, python, and the other
providers listed in `:help providers`. We could overload `vim.ui` to
serve that purpose as the single "providers" namespace, but
`vim.ui.nodejs()` for example seems awkward.
Solution:
`vim.env` currently has too narrow of a purpose. Overload it to also be
a namespace for `vim.env.open`.
diff --git a/runtime/lua/vim/_meta.lua b/runtime/lua/vim/_meta.lua
index 913f1fe20348..17d05ff37595 100644
--- a/runtime/lua/vim/_meta.lua
+++ b/runtime/lua/vim/_meta.lua
@@ -37,8 +37,28 @@ local options_info = setmetatable({}, {
end,
})
-vim.env = setmetatable({}, {
- __index = function(_, k)
+vim.env = setmetatable({
+ open = setmetatable({}, {
+ __call = function(_, uri)
+ print('xxxxx'..uri)
+ return true
+ end,
+ __tostring = function()
+ local v = vim.fn.getenv('open')
+ if v == vim.NIL then
+ return nil
+ end
+ return v
+ end,
+ })
+ },
+ {
+ __index = function(t, k, ...)
+ if k == 'open' then
+ error()
+ -- vim.print({...})
+ -- return rawget(t, k)
+ end
local v = vim.fn.getenv(k)
if v == vim.NIL then
return nil
Problem: in #24046 the signature of buf.clear_references() changed, which
indirectly breaks callers that were passing "ignored" args.
Solution: because util.buf_clear_references() already defaulted to "current buffer",
the change to buf.clear_references() isn't actually needed, so just revert it.
- fix lint / analysis warnings
- locations_to_items(): get default offset_encoding from active client
- character_offset(): get default offset_encoding from active client
Commit 37079fc moved inlay_hint to vim.lsp() but in the process did
missed converting a call to disable/enable which are now local.
Fixes the below error when trying to toggle inlay hints.
E5108: Error executing lua /usr/local/share/nvim/runtime/lua/vim/lsp/inlay_hint.lua:248: attempt to call field 'disable' (a nil value)
stack traceback:
/usr/local/share/nvim/runtime/lua/vim/lsp/inlay_hint.lua:248: in function 'toggle'
/usr/local/share/nvim/runtime/lua/vim/lsp/inlay_hint.lua:310: in function 'inlay_hint'
[string ":lua"]:1: in main chunk
Problem:
vim_lsp_inlayhint: Error executing lua: .../lsp/_inlay_hint.lua:249: attempt to index field 'applied' (a nil value)
Solution:
Assign {} to bufstates.applied in on_reload
fixes#24172
Problem:
On running `zig fmt` manually, the on_lines callback and the
server both detach (for some reason), and both of them call
`clear()`. This fixes it, otherwise the second one to detach
has an error in `reset_timer` since the bufstate doesn't exist
Solution:
* exit early in clear if `bufstates[bufnr]` is nil
* set bufstatte.enabled to true on reload instead of making bufstate nil
Problem:
The decoration provider clears the whole buffer then redraws all the hints every
time the window was redrawn. This may lead to an infinite loop.
Solution:
Store the last applied version for a line and only clear and redraw the line if
the buffer version has changed.
Enforce consistent terminology (defined in
`gen_help_html.lua:spell_dict`) for common misspellings.
This does not spellcheck English in general (perhaps a future TODO,
though it may be noisy).
Problem:
Spacing around inlay hints has the same highlight as the hint itself.
The LSP spec for inlay hints specifically mentions the padding should not be
coloured:
/**
Render padding before the hint.
Note: Padding should use the editor's background color, not the
background color of the hint itself. That means padding can be used
to visually align/separate an inlay hint.
*/
paddingLeft?: boolean;
/**
Render padding after the hint.
Note: Padding should use the editor's background color, not the
background color of the hint itself. That means padding can be used
to visually align/separate an inlay hint.
*/
paddingRight?: boolean;
Solution:
Add the space as separate parts of the virtual text, don't add the space to the
text itself.
Add automatic refresh and a public interface on top of #23736
* add on_reload, on_detach handlers in `enable()` buf_attach, and
LspDetach autocommand in case of manual detach
* unify `__buffers` and `hint_cache_by_buf`
* use callback bufnr in `on_lines` callback, bufstate: remove __index override
* move user-facing functions into vim.lsp.buf, unify enable/disable/toggle
Closes#18086
Previously, filtering code actions with the "only" option failed
if the code action kind contained special Lua pattern chars such as "-"
(e.g. the ocaml language server supports a "type-annotate" code action).
Solution: use string comparison instead of string.find
`client.messages` could grow unbounded because the default handler only
added new messages, never removing them.
A user either had to consume the messages by calling
`vim.lsp.util.get_progress_messages` or by manually removing them from
`client.messages.progress`. If they didn't do that, using LSP
effectively leaked memory.
To fix this, this deprecates the `messages` property and instead adds a
`progress` ring buffer that only keeps at most 50 messages. In addition
it deprecates `vim.lsp.util.get_progress_messages` in favour of a new
`vim.lsp.status()` and also promotes the `LspProgressUpdate` user
autocmd to a regular autocmd to allow users to pattern match on the
progress kind.
Also closes https://github.com/neovim/neovim/pull/20327
feat(lua): add vim.system()
Problem:
Handling system commands in Lua is tedious and error-prone:
- vim.fn.jobstart() is vimscript and comes with all limitations attached to typval.
- vim.loop.spawn is too low level
Solution:
Add vim.system().
Partly inspired by Python's subprocess module
Does not expose any libuv objects.
PROBLEM:
Whenever any text edits are applied to the buffer, the `marks` part of those
lines will be lost. This is mostly problematic for code formatters that format
the whole buffer like `prettier`, `luafmt`, ...
When doing atomic changes inside a vim doc, vim keeps track of those changes and
can update the positions of marks accordingly, but in this case we have a whole
doc that changed. There's no simple way to update the positions of all marks
from the previous document state to the new document state.
SOLUTION:
* save marks right before `nvim_buf_set_lines` is called inside `apply_text_edits`
* check if any marks were lost after doing `nvim_buf_set_lines`
* restore those marks to the previous positions
TEST CASE:
* have a formatter enabled
* open any file
* create a couple of marks
* indent the whole file to the right
* save the file
Before this change: all marks will be removed.
After this change: they will be preserved.
Fixes#14307
