Problem:
Any random ftplugin or other autocmd, can throw an error when
`:checktime` reloads a buffer. This causes a trace which makes it look
like an issue with `autoread.lua`.
vim.schedule callback: …/runtime/lua/nvim/autoread.lua:146:
FileType Autocommands for "*"..function <SNR>1_LoadFTPlugin[20] ..script
…/runtime/ftplugin/help.lua: Vim(runtime):E5113: Lua chunk:
…/runtime/lua/vim/treesitter.lua:216: Index out of bounds
stack traceback:
[C]: in function 'nvim_buf_get_text'
…/runtime/lua/vim/treesitter.lua:216: in function 'get_node_text'
…/runtime/lua/vim/treesitter/query.lua:558: in function 'handler'
…/runtime/lua/vim/treesitter/query.lua:843: in function '_match_predicates'
…/runtime/lua/vim/treesitter/query.lua:1082: in function '(for generator)'
…/runtime/ftplugin/help.lua:91: in function 'runnables'
…/runtime/ftplugin/help.lua:124: in main chunk
[C]: in function 'checktime'
…/runtime/lua/nvim/autoread.lua:146: in function <…/runtime/lua/nvim/autoread.lua:138>
Solution:
Use pcall() and surface the error via nvim_echo.
Problem:
Old 'autoread' only did `:checktime` on focus-change and shell (":!")
commands, and only for non-hidden buffers. Since 'autoread' is now
driven by OS filewatcher events, buffers are updated much more eagerly.
This should be surfaced to the user somehow, either via a carefully
placed notification, or a minimal UI indicator.
A "notification" would be noisy, unless it is conditional on specific
circumstances (e.g. when "many" buffers are updated).
Solution:
Use the existing 'busy' buffer-local option as a subtle hint about
activity.
Problem: The semantic token module is using its own debounce timer for
the buffer on_lines event. If its internal debounce is shorter than the
changetracking module's debounce, it's possible for semantic token
requests to fire for changed buffers before the textDocument/didChange
notification is sent to the server.
Solution: Trigger semantic token requests from the LspNotify autocmd
when the method is the didChange or didOpen notifications, which
enforces a strict happens-before relationship for the sync change
notification followed by a semantic token request.
Note: There is still an internal debounce mechanism in the semantic
token module to handle other debouncing needs specific to its
functionality, such as debouncing server refresh notifications and
handling WinScrolled events when using range requests.
Problem: Keys valid in CTRL-X mode are never mapped while insert
completion is active, so <C-N> and <C-P> cannot be remapped
for completion started by complete().
Solution: Do not disable mappings in CTRL_X_EVAL mode. In this mode a
mapping cannot interfere with selecting the completion
method, which is what the no-mapping rule exists for.
related: vim/vim#6440
related: vim/vim#16880
closes: vim/vim#20489076585e6ad
Co-authored-by: Thomas M Kehrenberg <tmke8@posteo.net>
Problem: The "%" command jumps to parens and braces inside comments,
unlike the "=" operator (cindent), which ignores them.
Solution: When 'comments' defines C-style comments and "%" is not in
'cpoptions', skip matching parens inside such comments, except
when the cursor is inside a comment so a match there can still
be found.
fixes: vim/vim#20329
related: vim/vim#20111
closes: vim/vim#20491b8a109dcfb
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Problem: Running `vim.filetype.match()` when current working directory
was removed from disk throws a `vim.fs.abspath` assertion error.
However, the matching might still be possible without trying to match
against full path (like if it is a known extension).
Solution: Safely compute absolute path and ignore it if it errors.
Problem: Diagnostic virtual lines are hardcoded with "scroll" for
virt_lines_overflow option.
Solution: Add a `overflow` option to `virtual_lines` config
to support "wrap", "scroll", "trunc", and "auto".
Problem:
The 'autoread' option only checks for file changes reactively — on
FocusGained, :checktime, CmdlineEnter, etc. — by polling timestamps.
External changes are not detected until the user interacts with Neovim.
Solution:
Add a core module (runtime/lua/nvim/autoread.lua) enabled from
runtime/plugin/autoread.lua that watches each buffer's file using
vim._watch.watch() (libuv fs_event). On change detection it calls
:checktime, which invokes the existing buf_check_timestamp() logic
for reload/prompt handling. Watchers are managed via autocmds tied
to buffer lifecycle events and respect the 'autoread' option (global
and buffer-local).
- Explicitly match the dot accessor
- Exclude the qualifier when matching qualified function calls
The dot accessor lookbehind on builtin function calls was slow, matching
across expression based dictionary accessors was visually inconsistent,
and it's arguably more semantically correct.
closes: vim/vim#2048178094ff1d7
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem:
Flickering may occur when paging up/down in big files, as ranges for semantic
tokens are requested. This happens with LSP servers like gopls which return
"/full" semantic tokens if the file is too big, where we fall back to
viewport-range token retrievals.
Solution:
Broaden the requested ranges to one viewport of "overscan" on each side plus
some padding if possible:
(viewport_topline - viewport_height)..(viewport_botline + viewport_height)
Problem:
`nvim -u NONE -d <(xxd one) <(xxd two)` has weird behavior.
Process substitution `<(...)` is a pipe and not a seekable file.
Test case:
cat /dev/random | head -c 10240 > one
cp one two
cat /dev/random | head -c 10240 >> two
nvim -u NONE -d <(xxd one) <(xxd two)
Solution:
Workaround the issue by skipping `nvim.difftool` if the 2 args are not
directories; fall-through to the builtin diff handling.
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
Problem: unmarking a regular file when there are directories in the markings
list also removes the 2match highlight from those directories.
Solution: correctly rebuild the match pattern from the remaining markings,
using the right regex trailer for each entry in the list.
closes: vim/vim#20461affd4b5964
Co-authored-by: J. Paulo Seibt <jpseibt@gmail.com>
Problem:
A text edit positioned entirely past the last buffer line, with
newText ending in a newline, leaves a stray blank line: the
past-the-end path appends the trailing empty fragment produced by
vim.split() and does not set has_eol_text_edit, so the end-of-buffer
cleanup is skipped. Formatting servers emit such edits whenever
formatting moves text to the end of a document.
Regression from ec94014cd1 (#20137), which split the past-the-end
fast path off the clamp path that sets the flag.
Solution:
Set has_eol_text_edit in the past-the-end path, like the adjacent
path that clamps end_row.
Problem:
When a server sends workspace/codeLens/refresh while an automatic codelens
request is already scheduled, Nvim ignores the server refresh. This can leave
rendered codelens text stale until another buffer edit triggers a new request.
Solution:
Cancel the pending automatic request and send the server-requested refresh
immediately. This preserves request coalescing while giving explicit server
refreshes priority.
Problem:
* 'shellcmdflag' states that its default value is set according to the
value of 'shell', but this behavior is not yet implemented on Windows.
The same applies to 'shellpipe', 'shellredir', and 'shellxquote'.
* On Windows, Git is often installed in paths containing spaces, and we
still do not correctly resolve the sh executable name as described in
'shell'.
* On Windows, the default value of 'shellslash' is always `false`,
which causes Unix-like shells to interpret `\` in paths returned by
some functions as escape charaters.
Solution:
Use a simple rule table to detect common shells (e.g. `cmd`,
`powershell`, shells whose names contain `csh` or `sh`) and apply
best-effort defaults, while leaving more complex scenarios to user
configuration.
Problem: docs say {str} is capped at 256 and longer returns an empty list.
Solution: it's 1024, and {str} plus each candidate are just truncated to
that, not rejected; fix the text.
closes: vim/vim#20453595d0a77e4
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: Extmark has support for horizontal scrolling and truncating, but not wrapping.
Solution: Extend virt_lines_overflow flags to support "wrap" and "auto" based on proposed changes in #18282.
Problem: In command-line completion with a popup menu ('wildoptions'
contains "pum"), the info popup shown next to the menu could
not be scrolled, unlike the Insert mode completion info popup
which scrolls with the mouse wheel.
Solution: When the mouse pointer is on top of the info popup, scroll it
with the mouse wheel in command-line mode as well, without
closing the completion popup menu.
closes: vim/vim#20146closes: vim/vim#2041896dbab257a
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Problem:
- `pos.cursor()` receives a table contains `row` and `col` as arguments,
but `pos:to_cursor` returns `row` and `col` directly
without wrapping them in a table.
- `pos.mark()`/`pos:to_mark` can already handle unpacked `row` `col`.
Solution:
Make `pos:to_cursor()` return a `row` and `col` in a table.
Problem:
`vim.pos.cursor(vim.api.nvim_get_current_buf(win), vim.api.nvim_win_get_cursor(win))`
is too verbose to create a cursor position of a window,
but it is a common use case.
Solution:
Overload `vim.pos.cursor()`, so that it accepts `win` as an argument when `pos` is omitted.
Problem:
When `vim.hl.range(0, …, { timeout = N })` is called, the deferred
`range_hl_clear` captures `buf=0`, which resolves to an arbitrary
"current buffer" at timeout. This may cause a stale highlight that never
gets cleared.
Solution:
Resolve `buf=0` explicitly, before `range_hl_clear` captures it.
Problem:
The comma form of 'winborder' is split with copy_option_part(),
whose skip_to_option_part() eats spaces after a comma, and empty
fields are rejected.
Solution:
Split the comma form literally on ',', keeping empty fields and
single-space fields.
Problem: [security]: another possible code execution with python complete
(David Carliez)
Solution: Strip default expressions and annotations from generated
source for pythoncomplete and python3complete.
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-65p9-mwwx-7468c8c63673bc
Co-authored-by: Christian Brabandt <cb@256bit.org>
This was originally used because we needed a lua interpreter to run the
standalone _busted_ lua application (except we used fuckery behind the
scenes to fake its binary dependencies with our own binary
dependencies). Now we longer do that, we instead run `test.harness` as a
standard nvim -l script. as this mode is no longer used in tests it
risks going to bitrot anyway.
NB: -ll mode still had some theoretical benefits like quicker
initialization and more "native" printing behavior, etc.
But we can incrementally work on "nvim -l" mode instead
of maintaining a separate special thing.
Problem:
We perform validations after the request handler is called.
When these validations fail, `error()` and `assert()` will prevent the
subsequent code from running, meaning the server will never receive a response.
Solution:
Always respond to requests.
Problem:
This doc on `vim.lsp.completion.get()`:
--- Used by the default LSP |omnicompletion| provider |vim.lsp.omnifunc()|, thus |i_CTRL-X_CTRL-O|
--- invokes this in LSP-enabled buffers. Use CTRL-Y to select an item from the completion menu.
--- |complete_CTRL-Y|
...makes two wrong claims:
1. "Used by the default LSP omnicompletion provider vim.lsp.omnifunc()"
- `_omnifunc` does not call `M.get()`, it calls the internal `trigger()` directly.
2. "thus |i_CTRL-X_CTRL-O| invokes this in LSP-enabled buffers"
- The two paths use different client sets:
- `M.get()` reads `buf_handles[bufnr].clients` (clients
explicitly registered via `vim.lsp.completion.enable(true, ...)`).
- `_omnifunc` reads `lsp.get_clients({method='textDocument/completion'})` (every
completion client, regardless of `enable()`).
Solution:
Update docs.
Co-authored-by: Koichi Shiraishi <zchee.io@gmail.com>
Co-authored-by: y9san9 / Alex Sokol <y9san9@gmail.com>
Co-authored-by: adv0r <>
Problem:
Diagnostic highlight groups were applied by iterating and calling
`vim.hl.range` for each group individually. That resulted in multiple
extmarks with the same priority being created separately, which does not
allow `DiagnosticUnnecessary` and `DiagnosticDeprecated` with matching
options override `Diagnostic*` styling.
Solution:
Pass the list of hl-groups to `vim.hl.range` so they are applied
together in the correct order.
Problem:
PR #38340 prevented messages we receive with id:null from being
incorrectly classified as notifications, but caused us to ignore all
messages with id:null, including requests.
Solution:
Handle requests with id:null. When we receive a request, we only need to
respond based on the `method` and `param`.
(The original so-called `notification_received` in the test was actually
semantically `request_or_notification_received`.)
