PROBLEM:
Cursor briefly flickers in cmdline when the "written" message is printed
(very noticeable in Neovide with cursor animation).
SOLUTION:
- Mark UI "busy" (cursor hidden) while emitting the message, as done for
the search message (cb2ca54331).
- Note: ff68fd6b8a moved the message from `filemess()` into
`buf_write..msg_progress`.
- Fix a bug in `tui.c:flush_buf` which manifested after this change. See
ANALYSIS below. https://github.com/libuv/libuv/issues/5182
ANALYSIS:
After this change...
ui_busy_start();
set_keep_msg(msg_progress(IObuff, msg_id, "success", 0, true, true), 0);
ui_busy_stop();
...ASAN analyzer fails on tui_spec.lua test "with non-tty (pipe) stdout/stderr":
2026-07-04T14:09:28.9521023Z = ==32405==ERROR: AddressSanitizer: ABRT on unknown address 0x03e900007e95
...
4 0x7f5506a288fe in abort stdlib/abort.c:79:7
5 0x559afd7113a2 in uv__epoll_ctl_flush
build/src/libuv/src/unix/linux.c:1335:7
6 0x559afd710a81 in uv__io_poll
build/src/libuv/src/unix/linux.c:1448:9
7 0x559afd6f67a7 in uv_run
build/src/libuv/src/unix/core.c:460:5
8 0x559afd2a72cc in flush_buf
nvim/tui/tui.c:2642:5
9 0x559afd2bce9f in tui_flush
nvim/tui/tui.c:1747:3
10 0x559afd2f39a0 in ui_client_event_flush
nvim/auto/ui_events_client.generated.h:64:3
11 0x559afcb8e014 in parse_msgpack
nvim/msgpack_rpc/channel.c:255:11
12 0x559afcb840e7 in receive_msgpack
nvim/msgpack_rpc/channel.c:217:5
13 0x559afc53b2af in read_event
nvim/event/rstream.c:180:23
14 0x559afc53ad52 in invoke_read_cb
nvim/event/rstream.c:233:3
15 0x559afc5382d6 in read_cb
nvim/event/rstream.c:135:3
16 0x559afd707b25 in uv__read
build/src/libuv/src/unix/stream.c:1145:7
17 0x559afd70744a in uv__stream_io
build/src/libuv/src/unix/stream.c:1208:5
18 0x559afd6f727e in uv__io_cb
build/src/libuv/src/unix/core.c:930:5
19 0x559afd710d7a in uv__io_poll
build/src/libuv/src/unix/linux.c:1546:11
20 0x559afd6f67a7 in uv_run
build/src/libuv/src/unix/core.c:460:5
21 0x559afc526e2d in loop_uv_run
nvim/event/loop.c:59:3
22 0x559afc526aa4 in loop_poll_events
nvim/event/loop.c:80:26
23 0x559afd2fdbb7 in ui_client_run
nvim/ui_client.c:172:5
24 0x559afc920d7b in main /home/runner/work/neovim/neovim/src/nvim/main.c:355:5
25 0x7f5506a2a1c9 in __libc_start_call_main
main.h:58:16
26 0x7f5506a2a28a in __libc_start_main csu/../csu/libc-start.c:360:3
27 0x559afbd6d254 in _start
The abort requires two rare conditions:
1. a `uv_write` whose buffer array *ends* in a zero-length buffer, which only
happens by "flush while cursor-hidden".
2. an output fd that *epoll cannot watch*. The only CI test with such an fd is
tui_spec.lua "with non-tty (pipe) stdout/stderr", which runs a TUI with
`stdout > /dev/null`, then runs `:w testF`, which triggers the "written"
message.
Our change guarantees trailing-empty flushes (`:w` fires busy + `ui_flush()`
while busy) in the only test that runs a TUI on `/dev/null`.
0. In a normal (non-busy) no-sync flush, post always contains `cursor_normal`.
1. Our change emits:
```
busy_start → msg_progress("…written") → ui_flush → busy_stop
```
2. TUI flushes *while busy*, so `should_invisible() = true` and `flush_buf`
skips the cursor-restore string (`bufs[2]` is zero-length).
3. libuv *cannot complete* a write whose tail is a zero-length buffer: EVERY
trailing-empty write goes through epoll, even when every byte was already
written. https://github.com/libuv/libuv/issues/5182
4. In `tui_spec.lua:3298`, the output fd is `/dev/null`, whose kernel
`file_operations` has no `.poll` method (`drivers/char/mem.c`), so
`EPOLL_CTL_ADD` fails with `EPERM`.
Trailing empty buffers are semantically pointless, and libuv punishes
them: forced async, one epoll round-trip *per trailing empty*, plus
a 0-byte `write()` syscall.
Helped-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Helped-by: Fred Sundvik <fsundvik@gmail.com>
Problem:
Plugins using RPC sockets cannot detect when the peer closes a
`sockconnect()` channel, so reconnect logic has no reliable trigger.
Solution:
Add a `ChanClose` event with channel info before the channel is removed,
matching the existing `ChanOpen`/`ChanInfo` event model.
Problem:
FAILED …/defaults_spec.lua @ 1286: stdpath() avoids DOS 8.3 filenames for "cache" and "run"
Expected values to be equal.
Expected:
"XTEST_~1"
Actual:
"XTEST_~2"
stack traceback:
…/defaults_spec.lua:1296: in function <…/defaults_spec.lua:1286>
Solution:
Relax the test.
fix(iconv): conversion to utf-16be using iconv is inconsistent
vim-patch:9.2.0769
Problem: enc_canonize function changes utf-16be to utf-16 but in linux
type utf-16 defaults to utf-16le.
Solution: Creating a separate entry for utf-16be in enc_canon_table.
Note: the effect is only visible on iconv implementations that
treat "utf-16" and "utf-16be" differently, so the test does
not necessarily fail on an unpatched Vim. But the bug is
visible in vim.iconv. (Manoj Panda)
from: vim/vim@2a63f74
closes: neovim#40262
Signed-off-by: Manoj Panda <manojpandawork@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Some test_mksession tests do not cleanup all the state
Solution: Add commands to clean up state introduced by the test
(Illia Bobyr)
Before this change the following 4 tests were failing when executed
individually:
Test_mksession_arglocal_localdir
Test_mksession_buffer_count
Test_mksession_one_buffer_two_windows
Test_mksession_winminheight
As in
```
TEST_FILTER=winminheight make test_mksession
```
Yet, when ran as part of the whole test suite they succeeded.
This was due to some state leaking from one test into another.
I think this is bad, as it can confuse someone making changes in the
relevant area.
`Test_mksession_winminheight` is actually still broken a bit, and
requires `winheight` and `winwidth` set at the beginning of the test,
rather than later, when it actually matters. This exposes a subtle bug
in the session restore script. I have a patch in a separate commit.
closes: vim/vim#20691834b8d218f
Co-authored-by: Illia Bobyr <illia.bobyr@gmail.com>
Problem: tests: Test_fuzzy_completion_bufname_fullpath() creates an
unnecessary directory with the name of a file.
Solution: Only create the parent directory of the file (zeertzjq).
closes: vim/vim#2069598efa50279
Problem:
The dir.lua "-" mapping cannot be easily overridden (because of autocmd
ordering).
Solution:
- Move it to defaults.lua.
- Also to be extra polite: fall back to builtin `-` motion if the user
disabled the `dir.lua` plugin.
Problem: tests: still some flaky screendump tests
(James McCoy)
Solution: Replace flaky VerifyScreenDump checks with assert_* assertions
for Test_visual_block_scroll and Test_scrolloffpad_with_folds,
and remove the now-unused dump files, mark those tests as
flaky (which happened previously for screendump tests
automatically) (Yasuhiro Matsumoto).
fixes: vim/vim#20096
related: vim/vim#20095cf5d7102b9
Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
Problem: tests: still a few flaky tests
Solution: Add WaitForAssert to test_messages.vim, use a smaller terminal
window for test_tabpanel, add TermWait() in test_messages
to handle DECQRM messages.
closes: vim/vim#200740bc64b19a2
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: tests: Some tests are flaky and cause CI to fail
Solution: Add WaitForAsserts() calls to reduce flakiness
closes: vim/vim#200501940bcb243
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Some code for 'autocompletedelay' is no longer needed now that
'autocompletedelay' doesn't block redraw (after 9.2.0739).
Solution: Remove unnecessary code. Also remove a duplicate screendump
and an outdated comment in test (zeertzjq)
closes: vim/vim#206860b86b97cc9
Problem: If 'autocompletedelay' is non-zero, 'autocomplete' doesn't
work when recording a register (after 9.2.0750).
Solution: Still produce K_COMPLETE_DELAY when recording a register, and
drop it in gotchars_add_byte() instead (zeertzjq).
This patch only changes the behavior when recording a register.
Replaying a register with 'autocomplete' still doesn't fully work
regardless of 'autocompletedelay', as 'autocomplete' isn't triggered
when there is pending input.
closes: vim/vim#20675a658728918
Problem: After 'autocompletedelay' was made non-blocking, the deferred
popup can misbehave: a pending autocomplete survives leaving
Insert mode and then keeps waking the editor in Normal mode,
the deferral is recorded into registers while recording a
macro, the popup appears an extra 'updatetime' late when
'autocompletedelay' is larger and a CursorHoldI autocommand
exists, CursorHoldI can fire twice without an intervening
keypress, and an open balloon is dismissed (after v9.2.0739)
Solution: Treat the deferral like CursorHold: only keep it pending in
Insert mode and not while recording, with pending typeahead,
or when completion is already active; drop it when Insert mode
ends; measure the delay from when the user typed so a
CursorHold in between does not push the popup back; and do not
let the deferral re-enable CursorHoldI or dismiss the balloon.
(Hirohito Higashi).
closes: vim/vim#206691f0f14bc2f
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Problem: 'autocompletedelay' interferes with i_CTRL-K (after 9.2.0739).
Solution: Clear the pending autocompltion from the previous key when a
new key is typed.
closes: vim/vim#206660d292e2067
Problem: 'autocompletedelay' interferes with CTRL-G U (after 9.2.0739).
Solution: Restore the flag for CTRL-G U.
related: vim/vim#8937
related: vim/vim#206669fb5b5d876
Problem: With a non-zero 'autocompletedelay', Insert-mode autocommands
(TextChangedI, TextChangedP, CursorMovedI) are delayed, and
while typing faster than the delay they are dropped entirely,
because the delay blocks the main loop.
Solution: Make 'autocompletedelay' non-blocking: instead of busy-waiting
before showing the popup menu, defer it with an input-wait
timeout (K_COMPLETE_DELAY) modeled on CursorHoldI, so typing
stays responsive and the Insert-mode autocommands fire normally.
The delay timer coexists with 'updatetime': the main loop waits for the
sooner of the two and triggers the event whose deadline was reached, so
'autocompletedelay' no longer shadows CursorHold timing. Changing the
completion leader, for example with Backspace, updates the visible popup
immediately like a zero delay; only the first popup is deferred.
Update the 'autocompletedelay' screendumps for the non-blocking display.
One test opened the menu with CTRL-N right after the delay expired and
could race with the deferred popup, so it now waits a little longer than
the delay before sending the key.
fixes: vim/vim#20591closes: vim/vim#205988ce43ea4e3
Also include some insexpand.c and ui.c changes from patch 9.2.0750.
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Problem:
On Windows, `fnamemodify('//foo/C$', ':h')` incorrectly removes `C$`
as a regular file name and returns `//foo`. However, this is a valid
UNC path, `foo` is a server name and `C$` is a share name.
The correct result should be `//foo/C$`.
Solution:
Extend `os_fileinfo2` and `FileInfo` with `prefix_off`, `rest_off` to
identify path types and logical root boundaries. ':h' can use this info
to prevent traversing past the logical root.
Examples:
/foo => /
//foo => // (POSIX)
//foo/bar => //foo (POSIX)
//server/share/foo => //server/share/ (Windows)
C:/foo => C:/
//?/C:/foo => //?/C:/
Co-authored-by: Barrett Ruth <br@barrettruth.com>
Problem:
vim.fs.dir() and vim.fs.find() drop errors returned by uv.fs_scandir().
Solution:
- vim.fs.dir():
- Return root scan failures as a secondary return value.
- Propagate recursive scan failures through the iterator. This allows
callers to distinguish unreadable directories from empty ones.
- vim.fs.find(): Collect errors during search, and return the list as
a second retval.
Problem: Session with multiple tabpages sets 'winminheight' to 0.
Solution: Only save 'winminheight' and 'winminwidth' once (zeertzjq).
related: vim/vim#8119
related: neovim/neovim#40493closes: vim/vim#20673294dec827d
- Replace newlines in the current cmdline with NULs when opening cmdwin,
and do the reverse when putting a cmdwin line back into the cmdline.
- Escape control characters with Ctrl-V when feeding cmdline.
Problem:
- If cmdwin window is split, ENTER in one does not close the others.
- If cmdwin is put into a different tabpage via <c-w>T, it stops working
(ENTER does not execute the cmd).
Solution:
- Close the buffer instead of the window.
- In the WinClosed handler, skip `M._cleanup()` unless this is the last
cmdwin window.
Problem: changed_lines got a hardcoded 0, so the changelist entry
and '. mark always recorded column 0 instead of where the edit
actually happened.
Solution: pass start_col instead. changelist now tracks the real
column.
Problem:
`:restart` does not preserve window layout, etc.
Solution:
- Change `:restart` to save/restore a session automatically.
- Introduce "bang" variant `:restart!` to restart *without* session
save/restore.
- Introduce `v:startreason`.
- `ZR` maps to `:restart!`.
Problem:
On Windows, channel jobs inherit Nvim's stdio, so a background job
writing to CON (e.g. gutentags) draws onto the TUI and stays until
redraw.
Solution:
Give Windows job stdin/stderr libuv-created pipes (UV_CREATE_PIPE)
instead of inherited fds, so libuv spawns the child with
CREATE_NO_WINDOW and CON writes no longer leak onto the TUI.
Problem:
- Lua<=>API roundtrips
- Although we prefer Lua for most business-logic code, doing this
conversion in C makes sense in this case because:
1. setting options is a hot path
2. most of the options logic lives in C
3. the current arrangement is MORE verbose and requires MORE code
Solution:
Move conversion to a C util.
- nvim_set_option_value passes the raw Object (scalar, Array, or Dict)
to `object_as_optval_for()` which flattens it to the canonical `:set`
string and validates the type.
- drop `convert_value_to_vim`, eliminate its roundtrip.
The added test shows the context, one expected a JSON field
to be a Object but it was a null value
pros: shows `vim.NIL` instead of `a userdata`
cons: the context `field 'foo'` is lost. I think this is generated
with internal magic which is hard to replicate.
Problem: Crash when reading truncated spellfile (MarkLee131)
Solution: Set sl_sofo to TRUE in set_sofo() once sl_sal has been
converted to the soundfold layout.
Supported by AI.
closes: vim/vim#20660488a3eed12
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: SSH keys and related filetypes not recognized
Solution: Detect sshpublickey, sshknownhosts sshauthorizedkeys and
sshallowedsigners filetypes, add syntax scripts for those
filetypes (Fionn Fitzmaurice)
This adds syntax highlighting for SSH public keys, as well as related
filetypes derived from this (SSH authorized keys, SSH known hosts and
SSH allowed signers).
Also add filetype detection based on the path and name.
closes: vim/vim#206356e66ebc0fd
Co-authored-by: Fionn Fitzmaurice <git@fionn.computer>
Problem: Mapped typed keys didn't interrupt completion in
complete_check() (Yikai Zhao)
Solution: Also interrupt when in_compl_func and not replaying a register.
(glepnir)
closes: vim/vim#5547closes: vim/vim#2064337d85f5f1a
Problem:
No lint for strtol().
Solution:
Add lint, and update existing usages.
Callers that previously got a (garbage) large positive value:
- `indent.c`: use getdigits() (intmax, no int truncation) with def=1 so
overflow/too-large values stay positive and fall through to the
existing "too big" check (E475).
- `file_search.c`: use getdigits() with def=255 so overflow/too-large
values keep the "max expand" (else) branch.
The other conversions (api/command.c, eval/window.c, highlight_group.c,
tui/tui.c) only diverge on pathological overflow inputs where strtol's
result was already garbage and the observable outcome is unchanged.
Problem:
`nvim_set_option_value` cannot "update" options similar to `:set opt=`,
`:set opt+=`, etc. The Lua impls of "vim.opt" / "vim.o" have incomplete,
bespoke reimplementations of those operations.
ref #38420
Solution:
- Add `operation` param to `nvim_set_option_value`, which may be "set",
"append", "prepend", or "remove".
- Use this feature to implement `vim.opt` / `vim.o`.
Problem:
`os.exit()` in `nvim -l` exits through normal teardown. But, as #39783 shows,
when it is called from a libuv callback, teardown polling the main loop
when inside `uv_run()` can trip the recursive poll guard and cause a crash.
Fast callbacks are not safe to teardown, so it's better to schedule an exit out
of a callback rather than convolutedly handle this as I tried before.
Solution:
Reject `os.exit()` from fast callbacks with `E5560` error.
