Problem:
Literal path comparison ignored one trailing slash for every buffer name,
including URIs. Generic URI syntax does not make a non-empty path
equivalent to the same path with a trailing slash, so distinct URI
buffers collapsed into one.
Solution:
Require equal lengths when comparing URI buffer names, while retaining
trailing-separator normalization for filesystem paths.
AI-assisted
Problem:
`shorten_fnames()` always redraws the statusline/tabline, even if no
buffer name changed. Since b296666e a temp context-switch
(`win_execute()`, `vim._with{win=}`) restores the CWD, so every such
switch flickers the message area.
Solution:
Redraw only if `shorten_buf_fname()` actually changed a name.
vim-patch:8.2.0992: Vim9: crash when using :import in the Vim command
vim-patch:8.2.2872: Python tests fail without the channel feature
vim-patch:8.2.3589: failure when "term_rows" of term_start() is an unusual value
vim-patch:8.2.3597: Vim seems to hang when writing a long text to a terminal
vim-patch:8.2.3761: focus change is not passed on to a terminal window
vim-patch:8.2.4157: terminal test fails because Windows sets the title
vim-patch:8.2.4535: filename modifer ":8" removes the filename
vim-patch:8.2.4758: when using an LSP channel want to get the message ID
vim-patch:0646047b6 runtime(doc): clarify term_start() I/O behavior for Unix pty and MS-Windows ConPTY
vim-patch:9.2.0412: channel: term_start() out_cb/err_cb no longer deliver raw chunks
vim-patch:9.2.0420: channel: cannot handle binary data via channel callbacks
vim-patch:9.2.0565: [security]: out-of-bounds read in update_snapshot()
vim-patch:ba43008a2 runtime(doc): Update vim9.txt revisions, standardizing SS1,3-7
vim-patch:9.2.1013: [security]: out-of-bounds access in libvterm CSI 8 t resize
vim-patch:9.2.1021: GTK: Cursor blinks irregularly
vim-patch:4b2d42c43 CI: Bump github/codeql-action
vim-patch:9.2.1022: popup: width changes while scrolling
vim-patch:9.2.1023: GvimExt: destructors of polymorphic classes are not virtual
vim-patch:8.2.3979: Vim9: the feature is not mentioned in the right places
vim-patch:9.0.0058: Win32: cannot test low level events
vim-patch:9.0.1604: errors from the codestyle test are a bit confusing
vim-patch:3052bdb: runtime(doc): update the default value for 'isk' on Windows
Problem:
Replaying a deleted Lua mapping, may call an arbitrary function.
RHS of a Lua mapping embeds its LuaRef (`<K_LUA><ref><CR>`). The raw
keys may outlive the ref (redobuff ".", CmdAtom `keys`). If the mapping
is deleted, replaying it either (1) dereferences a freed registry slot,
or (2) calls whatever callback reused the slot (autocmd, timer, other
mapping).
Solution:
Assign a monotonic (never recycled) id to Lua mappings and encode the
mapping keys as `<K_LUA><id><CR>`.
Note: in the case of Vimscript, a deleted function raises E117, but if
the function is redefined with the same name, the mapping will find it.
Alternatives?:
- Globally ensure `LuaRef` ids are not recycled.
- Problem: could exhaust `int` in a long-lived Nvim session? Also,
difficult to impl bc the "recycling" is done by `luaL_ref` itself.
ref: 5ac2e47acc
Problem:
An operator completed by a Lua `:omap` textobject emits
`CmdAtom.type="mapping"` (lhs-only, no keys) instead of `type="operator"`.
Analysis:
`atom_redo_set()` declined K_LUA, though the prepped redo
("op" + K_LUA + id + CR) is exactly what "." replays. A no-edit "g@"
emits nothing at all.
Solution:
- `atom_redo_set`: don't decline K_LUA; the redo route now captures the
operator atom.
- `atom_capture_cmd`: don't early-return if the frame has prepped redo.
- op_function(): save/restore redobuff when invoking 'operatorfunc',
like `call_user_func()` does for Vimscript. (Else the Lua callback
may clobber the prepped "g@" redo / dot-repeat.)
fix#41482
TODO:
- async Lua (timer/vim.schedule) can still clobber the pending dot-repeat...
Problem: LPeg is hosted on a single unreliable external hoster, forcing
is to mirror it in neovim/deps, which adds maintenance friction. Also,
we have already vendored the Lua `re.lua` module.
Solution: Vendor all of LPeg v1.1.0; as development is not very active
anymore, this should not add much overhead (and allow us to simplify in
particular the Zig build scripts).
Note: LPeg defines a `luaL_newlib` macro for Lua 5.1, which conflicts
with LuaJIT's extension. This requires inlining the macro defined in
`lptypes.h` and used in `lptree.c`; see README.md for the patch.
Nvim uses utf8proc or an older process involving "src/unicode/"
and "download-unicode-files.sh" to decouple unicode characters
from "mbyte.c".
These unicode patches should be auto N/A but the diff hunk xfuncname
is wrong for utf_char2cells().
Is it because of the `#ifdef`?
Need a volunteer to inspect if these patches still have relevant
changes
Nvim
```c
/// same as utf_composinglike but operating on UCS-4 values
bool utf_iscomposing(int c1, int c2, GraphemeState *state)
{
return (!utf8proc_grapheme_break_stateful(c1, c2, state)
|| arabic_combine(c1, c2));
}
```
Vim
```c
/*
* Return TRUE if "c" is a composing UTF-8 character. This means it will be
* drawn on top of the preceding character.
* Based on code from Markus Kuhn.
*/
int
utf_iscomposing(int c)
{
// Sorted list of non-overlapping intervals.
// Generated by ../runtime/tools/unicode.vim.
static struct interval combining[] =
{
{0x0300, 0x036f},
{0x0483, 0x0489},
{0x0591, 0x05bd},
// ...
{0x0300, 0x036f},
{0x0483, 0x0489},
{0x0591, 0x05bd},
};
return intable(combining, sizeof(combining), c);
}
```
Problem: A completion asked for with CTRL-X CTRL-O while
'autocompletedelay' is running is given the look of an
automatic one, the implicit "noselect" among it.
Solution: Turn autocompletion off where a typed key takes the completion
over. A completion already on screen goes on being what it
was (Hirohito Higashi).
closes: vim/vim#21158c8e432b266
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Problem: A SwapExists autocmd can re-open the buffer being edited,
causing ml_close() to free the memfile that
ml_open_file() still holds a local pointer to, causing
use-after-free.
Solution: After findswapname() returns, verify that buf->b_ml.ml_mfp
is still the same as the copy mfp we hold.
closes: vim/vim#211717aecb2cca8
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
The Vim "stuff" concept breaks the ability to reason about the call
stack and thus the boundaries of a `CmdAtom`: a stuffed translation ("x"
=> "dl") defers to the main loop. This "continuation" must be modeled in
`CmdAtom`, by checking global flags at undefined times, during undefined
circumstances.
Solution:
- After a stuffed "translation", eagerly execute the stuff buffer
(`exec_stuffed()`).
- Delete the CmdAtom "continuation" junk.
Note:
- op_colon runs its cmdline "nested", but that's fine because operators
already nest interactive sessions there (op_change runs edit()), and
the cmdline is frameless so the operator's frame can own/capture it.
Problem:
If an autocommand handler focuses the tab page we're closing during a
`:tabonly` (with some conditions), we hit an assert failure in
`win_close_othertab()`.
For this to occur, we need:
- `nvim_buf_delete()` to trigger `close_windows()` (as is done in
`cmdwin.lua`'s `_cleanup()`)
- `close_windows()` then calls `win_close_othertab()`, removing the
window (`win_free_mem()`)
- then in the caller, `tabpage_close_other()`, the loop continues (we
don't detect `tp_lastwin == wp` since we've unlinked the window)
- the loop assumes that `curtab != tp`
but we've refocused `curtab` so the `ex_win_close()` call passes `tp` as
`curtab`, causing the assert to fail
Solution:
Detect the focus of `curtab` and abort closing the tab.
Problem:
gen_help_html.lua only outputs HTML, but Typst is useful for producing PDFs.
Solution:
Add gen_one_typ() and ts_node_to_typ(), which mirror the existing
gen_one_html() and ts_node_to_html().
Problem:
Undo places the cursor wherever the cursor happened to sit at "save
time" (`uh_cursor` is sampled lazily on the first change).
Examples:
- `i` preserves, but `a` does not
- `diw`, `atest<Esc>`, `d^` abandon the original position
- `D`, `o` restore it (by accident).
Solution:
`composite` tracks the pending atom (and its `origin`) across frames.
A `stuffed` continuation frame inherits the `origin` + prepped redo.
Store `origin` info in the undo header, so undo can restore it.
- Not for a mid-command undo break (i_CTRL-G_u).
- Undoing a mapping restores where the mapping started (which
technically may be different than where the "edit" started).
Problem: `restore_size` is scoped to all of `makeopens()`, so a window
excluded by 'sessionoptions' latches it off for every tabpage written
afterwards: with `sessionoptions-=terminal`, a terminal in tab 2 makes
tab 3 restore with `wincmd =` instead of its stored sizes.
Solution: Recompute it per tabpage.
Problem:
An insert-session entered by a scheduled `feedkeys('i','n')` is
classified on entry (as "not typed"), and not reevaluated after that,
thus user input following it is not captured.
Repro: an `:imap` that does `feedkeys('<esc>','n')` and schedules
re-entering insert, emits one CmdAtom for the first press, then nothing
else.
Solution:
Sample `maptick` (ticked by `gotchars()` on typed input, including
mappings) at session start; if it advanced by session end, the session
is user input.
I got annoyed about so many repeated `win_float_pos` events
for the popupmenu. This fixes some of them but not all of them.
vibe-less explanation: `need_highlight_changed = true` is very expensive
should not be needed when using a window-local highlight namespace. This
was only necessary when overriding the global highlight namespace. This
can instead be handled by using the correct `hl_attr_active` instead of
`highlight_attr`.
Also `pum_grid.pending_comp_index_update` can be cleared when using
win_float_pos prior to redraw.
I wanted to add a test for no repeated win_float_pos event in the same
redraw:flush cycle but that requires deeper cleanups, like
getting rid of crazy redraw panic intermingled deep into insexpand.c
(if "state" is correct, a single update_screen() after the weird
multilayer recursive dance should be enough.)
Problem:
`nlua_pcall()` references `_G.debug.traceback`. If user code deletes it
or breaks it some other way, various Lua features are broken.
_G.debug = nil
vim.schedule(function() end)
vim.wait(100)
E5113: Lua chunk: attempt to index a nil value
stack traceback:
[C]: in function 'loop_poll'
[string "vim/_core/editor"]:176: in function 'wait'
crash.lua:3: in main chunk
PANIC: unprotected error in call to Lua API (attempt to index a nil value)
Solution:
Check `_G.debug.traceback` before using it as errfunc. If it's broken,
omit the traceback and say so in the error message.
Note: We could cache `_G.debug` in LUA_REGISTRYINDEX on startup, but
that would prevent plugins from providing custom functionality there
(and we happen to do so in `tui_spec.lua` for example).
libvterm reads the first three sub-parameters of an SGR 38:2 or 48:2 sequence
as R:G:B, so a colour space id shifts the channels: the empty slot becomes red
via CSI_ARG_MISSING truncating to 255, and green and blue move over one.
Skip the colour space id when the colon-separated group holds more than three
arguments. The group length comes from CSI_ARG_HAS_MORE rather than the raw
argument count, so a following semicolon-separated parameter is not consumed.
vim-patch:8.1.2195: Vim does not exit when the terminal window is last window
vim-patch:8.1.2219: no autocommand for open window with terminal
vim-patch:8.2.1160: Vim9: memory leak in allocated types
vim-patch:8.2.2331: Vim9: wrong error when modifying dict declared with :final
vim-patch:8.2.4153: MS-Windows: Global IME is no longer supported
vim-patch:8.2.4586: Vim9: no error for using lower case name for "func" argument
vim-patch:9.0.0627: "const" and "final" both make the type a constant
vim-patch:9.0.1605: crash when calling method on super in child constructor
vim-patch:9.0.1760: vim9 class problem with new() constructor
vim-patch:9.1.0050: Win32 Keyboard handling is sub-optimal
vim-patch:9.1.0270: a few minor issues to fix
vim-patch:fb745756d runtime(doc): add MsgArea to 'highlight' option description
vim-patch:f0837ba0b runtime(doc): In builtin overview use {buf} as param for appendbufline/setbufline
vim-patch:6081c1789 runtime(doc): update help-toc description
vim-patch:2afdb3a65 runtime(doc): Fix minor typo in options.txt
vim-patch:ba0062b0c runtime(helptoc): the helptoc package can be improved
vim-patch:9340aa1bf runtime(helptoc): add s keymap to split and jump to selected entry
vim-patch:b2e21cccc runtime(doc): Tweak documentation in vi_diff.txt
vim-patch:3913f13a7 runtime(doc): Improve :help builtin-function-list table formatting
vim-patch:b8f58dd69 runtime(doc): Fix typos in version9.txt
vim-patch:9.2.0973: Vim9: internal error when a class member is initialized with a closure
vim-patch:9.2.0974: tests: Test_clientserver_serverlist_list() is flaky
vim-patch:9.2.0975: Vim9: assignment to a member of an object member fails
vim-patch:9.2.0977: tests: test_terminal_visual_empty_listchars() is flaky
vim-patch:9.2.0988: tests: Test_terminal_csi_resize_oob() returns early
vim-patch:9.2.0989: libvterm: hang when rendering REP with no preceding char
vim-patch:9.2.0990: libvterm: crash when a scroll region outlives a resize
vim-patch:9.2.0992: popup filter gets the key at the hit-enter prompt
vim-patch:9.2.0994: Vim9: No error for :open during compilation
vim-patch:b618f7ea1 CI: Bump github/codeql-action
vim-patch:b7e0c1cb3 runtime(doc): correct typo in bug report in version5.txt
vim-patch:632abba51 runtime(doc): fix typos and grammar in CONTRIBUTING.md
vim-patch:9.2.0999: serverlist() fails when there is no connection to the server
vim-patch:9.2.1000: Vim9: listener_add() fails when given only a callback
vim-patch:9.2.1003: popup: border is not shown when the popup does not fit
vim-patch:3e46ee723 patch 9.2.1010: compile error when folding feature is disabled
Problem: ins_compl_dict_alloc() builds the same dict as
fill_complete_info_dict().
Solution: Call fill_complete_info_dict() instead (glepnir).
closes: vim/vim#21140303a153694
Problem: A function used through 'omnifunc' or 'complete' is called the
same way whether 'autocomplete' started the completion or a
key asked for one, so it cannot answer differently.
Solution: Report which of the two it is in complete_info() as "auto". It
is returned only when asked for in {what}, so what
complete_info() says by itself does not change
(Hirohito Higashi).
closes: vim/vim#211431f56c351de
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Problem: backupcopy=auto overwrites a file in place when umask is restrictive.
The probe treats permission restore as impossible and writes in
place, keeping the same inode.
Solution: When creating the probe file, open() applies umask, so a 0644
file becomes 0600 with umask 0077. Use fchmod() to fix the
permissions of the probe (Pranav Dwivedi).
closes: vim/vim#21137fd8aea135d
Co-authored-by: Pranav Dwivedi <dwivedipranav2021@gmail.com>
Problem: With 'completeopt' "fuzzy", a re-sort after complete() leaves the
last match unsorted at the end of the list.
Solution: Find the original text by its flag instead of assuming
compl_shows_dir points at it.
closes: vim/vim#211037e74722999
Problem:
The runs ":helptags", which needs the tree-sitter-vimdoc parser.
This may cause problems for package maintainers / distros?
Solution:
Use running to generate the tags, like the zig build already does.
It also errors on duplicate tags, which is good.
The `:helptags` command still uses treesitter.
Problem:
Parent commit regressed some behavior of the old C helptags-gen impl:
- helpfiles in sub-directories are named by basename, so :help fails
- "help-tags" always names "tags", never "tags-nl"
- E150 E151 E152 E153 are never reported
- existing tags file is not overwritten if no tags were found
- a duplicate tag aborts the run, skipping the remaining directories
- `*.TXT` and `*.FRX` (uppercase) are not recognized as helpfiles
- tree-sitter-vimdoc accepts tags that the C parser rejected: `*a|b*`
(breaks |links|) and unterminated `*tag`
- PUC Lua "<" compares with (localized) `strcoll()`, so the tags file is
not sorted by byte value (E432)
- requiring `vim.treesitter` at load time breaks :help itself, not just
:helptags, where the module is unavailable
- `vim.pack` runs :helptags for plugins that have no "doc/" directory,
so every install/update emits E150
Solution:
- Fail the build if generating helptags reports any `v:errmsg`.
- Restore old behavior: tags generated for runtime/doc are now identical
to those from the C implementation. Errors are non-fatal messages
instead of exceptions, so all directories are still processed.
- Load treesitter lazily, report a plain error if parser is missing.
Problem:
Tags are manually parsed in C which is not flexible and prone to errors.
Extending the help system to allow for other formats (e.g. Markdown)
would require a large rewrite in the C core, while with Treesitter it
only needs a query update.
Solution:
Use the power of treesitter to extract the tags from helpfiles.
- build: set `$VIMRUNTIME` when generating helptags, like
`cmake/Util.cmake` already does for other generators.
- fix(help): only accept tags delimited by whitespace. The old C parser
only accepted a `*tag*` preceded by start-of-line or whitespace and
followed by whitespace or end-of-line. The vimdoc parser also captures
tags followed by other text, e.g. `*$XDG_STATE_HOME*/.../logs` in
starting.txt, which caused an E154 duplicate tag error for docs that
were previously fine.
Problem:
In order for ui2 to graduate to the main "messages ui" its configuration
needs to graduate into actual options.
Solution:
Migrate some of its config to 'messagesopt':
- "maxheight" (note: currently this is an integer treated as
a "percentage"; if we want to support a row count we could allow
values with units, like `"42%"`)
- "pager"
- "timeout"
Also improves error messages:
messagesopt=hit-enter,history:500,bogus E474: Unknown item 'bogus'
messagesopt=hit-enter,history:500,progress:x E474: 'progress' must be one of: , c
messagesopt=hit-enter,history:abc E474: 'history' requires a number
Problem:
`vim.on_key()` callbacks are invoked for keys that `getchar()` consumes,
which never reach the main loop, and there is no way to tell such a key
apart. With ui2 the `on_key` handler activated after interactive
cmdline, handles it as `pager_char` (thus enters the ui2 pager).
Solution:
Skip `vim.on_key()` callbacks during `getchar()`/`getcharstr()`.
Problem: complete_info() omits "abbr_hlgroup" and "kind_hlgroup".
Solution: Keep the highlight group ID with the match instead of the
resolved attribute and add both entries to the returned items
(glepnir).
closes: vim/vim#211051c32cede0a
Problem: In the debugger ">up" and ">frame" select an older function call
frame, but get_funccal_local_ht() and the related functions check
current_funccal while returning a dictionary of the frame that
get_funccal() selected. A :def function keeps its local variables
on the vim9 stack, its funccall_T has no l: and a: dictionaries and
is allocated cleared, so with such a frame selected the returned
hashtab has a NULL ht_array and evaluating any variable name at the
debug prompt crashes in hash_lookup().
Solution: Check the funccal that is actually used and return NULL when it has
no l: variables, so that the variable is reported as undefined
instead.
closes: vim/vim#211115ad47b07af
Co-authored-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
1) The complete example plugin at :h write-plugin the end of the
documentation didn't reflect the snippets provided during the
tutorial. In most of the Add() function, interpolated strings are
used, but the final result used concatenated strings.
2) The example provided in readdir() to get a list of files ending in
".txt" didn't properly escape the dot in the regular expression:
readdir(dirname, {n -> n =~ '.txt$'})
This would match any file ending with "txt" that is at least 4
characters long, instead it should be:
readdir(dirname, {n -> n =~ '\.txt$'})
closes: vim/vim#2112363d08d4386
Co-authored-by: Josep Puigdemont <josep.puigdemont@gmail.com>
Problem:
When ui2 is enabled, opening an already-open file in another Neovim
instance results in the error `E812: Autocommands changed buffer…`.
Analysis:
On E812 the file is not loaded. The default SwapExists handler notifies
`W325: Ignoring swapfile…`, and ui2 shows that message by opening
a window, which is a temp context switch. `ctx_dirs_restore()`
re-shortens every buffer name on the way out, and `shorten_buf_fname()`
always frees and reallocates `b_sfname`. `readfile()` aliases `b_fname`
across `check_need_swap()` and compares the pointer to detect a rename.
Regression by b296666e41, which replaced the `cs_save_sfname` restore
(that kept curbuf's pointer) with `shorten_fnames(true)`.
Solution:
Keep the allocation in `shorten_buf_fname()` when the short name is
unchanged. Pointer stability is what the E200/E201/E812 guards actually
assert.
Problem:
A mapping that enters terminal-mode (`:FzfLua files` via `:startinsert`)
never reaches a composite-end: terminal-mode runs no "normal" CmdFrames.
The composite collects the entire terminal session (and more) into `lhs`.
E.g. if I have `<M-/>` mapped to open `:FzfLua files`, then interact
with fzf-lua UI, the emitted CmdAtom looks like:
<M-/>… => { type='mapping', lhs='<M-/><C-N><C-N><CR>', keys=nil }
Solution:
End the composite when terminal-mode is entered, which emits a more
meaningful and repeatable atom:
<M-/>… => { type='mapping', lhs='<M-/>', keys=nil }
Problem:
The "!" operator stuffs its cmdline continuation (`:.,.+1!`), so its
frame ends before capture (stuff pending) and the redo-prep disappears
with it.
!ipsort<CR> => { type='excmd', lhs=':.,.+1!sort<NL>', keys=':.,.+1!sort<NL>' }
Compare to builtin "." which works bc `do_bang()` completes the redo
(`!ip` + `sort<NL>`).
Solution:
Appoint the stuffed continuation frame as the "redo-prep" frame.
!ipsort<CR> => { type='operator', operator='!', lhs='!ipsort<NL>', keys='!ipsort<NL>' }
Notes:
- atom_cmd_end(): a frame ending with stuff pending re-points its
redo-prep to the next frame.
- atom_cmd_start(): a stuffed continuation frame (`KeyStuffed`) keeps
the redo-prep; flushed stuff discards it.
Problem:
1. `ctx_dirs_restore()` is the only chdir site that doesn't re-shorten
buffer names; `post_chdir()`, `update_cwd()` and `do_autochdir()` all
call `shorten_fnames(true)`. So after a temp window-context switch
that moved the CWD, every buffer's `b_fname` is still relative to the
other directory. ui2 renders messages in a float, and entering it is
such a switch, so with a `:bcd` in a `BufReadPost` handler 'statusline'
"%f" shows ".config/nvim/init.lua" while the CWD is already
`~/.config/nvim`, and :write resolves the name against it:
```
E212: Can't open file for writing: no such file or directory
```
2. `msg_multihl()` leaves `msg_ext_id` pointing at the caller's storage
when nothing was emitted (e.g. 'msg_silent'): the reset only ran on
a flush that produced chunks. The next message then ships a dead
stack frame as its msg_show id. After ":silent write" the id is
buf_write()'s `msg_id[MAXPATHL + 32]`:
```
id = "\0\0\0\0\0\0\0\0\29\0(<C6>k\24R\17p<C7><C7><C7>\1\0\0\0..."
```
Solution:
1. `shorten_fnames(true)` after restoring the CWD. Drop `cs_save_sfname`,
which was a partial workaround for the same bug.
2. Release the id in `msg_multihl()`, where it is set and the caller's
frame is still alive. Stop reading `.data.integer` out of a String
union member.
Problem:
With 'linebreak', a word is moved to the next screen line when it does
not fit on the current one. The check measures only the buffer text, so
inline virtual text anchored inside the word is not counted. The word is
kept on a line it cannot fit, and the virtual text is split across the
screen line boundary.
Solution:
Count the width of inline virtual text anchored within the word, so the
check uses the width that is actually displayed.
Problem:
`buf_write()` captures the buffer's `fname`/`sfname`/`ffname`, then emits its
progress-message before opening the file. This may run user code
synchronously: the `Progress` autocmd, and the `msg_show` handler of an
in-process UI (ui2). Either can change the CWD, and `shorten_fnames()`
then frees/reallocs every buffer's short name. The rest of `buf_write()`
reads the freed name...
"foldtext()" [New] 41L, 997B written
E212: Can't open file for writing: illegal byte sequence
ASAN, with ui2 enabled and a `BufEnter` handler that runs `:lcd`:
READ path_skip_sep <- path_tail <- match_file_list <- buf_write
FREE shorten_buf_fname <- shorten_fnames <- update_cwd <- set_curbuf
<- win_set_buf <- nvim_open_win <- ui2 msg_show handler
<- ui_call_msg_show <- msg_ext_ui_flush <- buf_write
Solution:
Copy the names after the `*Pre` autocmds.
Note: `readfile()` has the same shape, but its messages pass no
progress-id, so they skip `msg_progress()`. Safe, for now...
The perf cost is negligible, but it's easy to address so might as well.
CID 653826: Performance inefficiencies (PASS_BY_VALUE)
/src/nvim/input_cmdatom.c: 385 in atom_push_raw()
384 /// Takes ownership of the atom's allocated members. Caller sets `atom.changed`.
>>> CID 653826: Performance inefficiencies (PASS_BY_VALUE)
>>> Passing parameter atom of type "CmdAtom" (size 176 bytes) by value, which exceeds the low threshold of 128 bytes.
385 void atom_push_raw(bool cascade, CmdAtom atom)
CID 653825: Performance inefficiencies (PASS_BY_VALUE)
/src/nvim/input_cmdatom.c: 438 in atom_stage_set()
436 /// Stages an atom built before its command executes (do_pending_operator() prep-exempt, Visual
437 /// ops), in the command's frame; pushed at frame end, once `changed` is known.
>>> CID 653825: Performance inefficiencies (PASS_BY_VALUE)
>>> Passing parameter atom of type "CmdAtom" (size 176 bytes) by value, which exceeds the low threshold of 128 bytes.
438 static void atom_stage_set(CmdAtom atom)
CID 653824: Performance inefficiencies (PASS_BY_VALUE)
/src/nvim/input_cmdatom.c: 427 in atom_push()
425 /// Pushes an atom (emit + maybe cascade), or drops it if replay/Visual/internal-op already
426 /// in-progress.
>>> CID 653824: Performance inefficiencies (PASS_BY_VALUE)
>>> Passing parameter atom of type "CmdAtom" (size 176 bytes) by value, which exceeds the low threshold of 128 bytes.
427 static void atom_push(bool cascade, CmdAtom atom)
Problem:
A mapping that ends mid-operation (`nnoremap ,D d`) emits a content-free
"mapping" atom plus a `pending` field, and the "continuation" motion
arrives as a sibling atom. Consumers must stitch the two together (which
has broken cases, e.g. Insert-opening mappings (",i") lose their session
entirely).
- ",i": the session atom is dropped bc the mapping RHS is consumed
before the session starts (typebuf_maplen()==0), so
atom_is_user_input()=false.
- ":normal"-in-opfunc: the opfunc internal "v..y" session (a) became
kVatomTyped just because the deferred composite was open, masking the
real operator capture via atom_captures, and (b) its nested frames
re-derived the outer redo.
- "Motion" based on `moved=true`, has false negatives.
- `CmdAtom.remap` is unnecessary, and clutters the docs/usage.
Solution:
- Introduce `frame_id` to identify CmdFrames.
- Classify `type=motion` better, via `NV_MOTION` flag on the `nv_cmds` table.
- Drop `CmdAtom.pending`, `CmdAtom.remap`.
- Defer atom_composite_end() at the clock edge while an operator is
pending, Visual is active, or `restart_edit` is set: the composite
keeps collecting, so the continuation is captured in the mapping atom.
- ",i": Now an open composite counts as user input.
- ":normal"-in-opfunc: Now handled correctly.
- `remap` is now decided by `composite.payload || 0 subatoms`.
atom_payload_mark() records the read the resolution never captures.
- `toplevel` is now decided by `CmdFrame.parent == NULL`.
before/after:
INPUT BEFORE AFTER
---------------------------------------------------------------------
,D w {mapping lhs=,D pending=operator} {operator lhs=,Dw keys=dw}
+ {operator keys=dw}
ysiw" {mapping lhs=ys pending=operator} {operator lhs=ysiw" keys=g@iw"}
+ {operator lhs=g@iw"}
,v d {mapping pending=visual} {visual lhs=,vd keys=viwd}
+ {visual lhs=viwd}
,i XY<Esc> {normal keys=i lhs=,iXY<Esc>} {insert keys=1iXY<Esc> text=XY}
* build(deps): bump tree-sitter to baad4174e
* build(deps): bump wasmtime to v48.0.0
Tree-sitter bumped their wasmtime dependency from v36 to v48 (the new LTS), so we must follow suit. This change brings in significant performance improvements for wasm parsers (although they are still significantly slower than native parsers).
Problem:
- `lhs` is not fully realized. E.g. for a "payload" mapping
`lhs` omits the `getchar()` payload during a mapping (vim-surround
`ds'` reports `lhs="ds"`). This means plugins like vim-repeat are
still needed...
- The "delta" fields of a CmdAtom are calculated too late.
- `<abuf>` and `changed` check whatever (wrong) buffer a command
(":bnext") might land in.
- CTRL-W_w between two windows on the same buffer reports type="motion".
Solution:
- `CmdOrigin` samples (buf/win/cursor/changedtick) at each "scope" entry
(CmdFrame, composite, Visual session, insert session).
- `dd<C-w>l` reports `changed=true` for the buffer it edited, regardless
of where the cursor ends up.
- New fields:
- `pos`: cursor position at command start.
- `moved`: indicates whether the cursor moved (in same buffer).
- `undoseq`: undo state at settlement.
- lhs now includes the payload: "ds)" reports lhs="ds)" instead of "ds".
- Easy for users to "replay" any atom.
- Rename: type "command" => "normal", "ex" => "excmd"; `arg` => `cmdarg`
- Drop `cascade` field (no reason to expose it)
Problem: Heap-buffer-overflow in spell_suggest() when the cursor is
beyond the end of the line, because a SpellFileMissing
autocommand changed the buffer (dvaave2025).
Solution: parse_spelllang() may run autocommands, so validate the cursor
position and re-take the saved position afterwards.
fixes: vim/vim#21097closes: vim/vim#21100
Supported by AI.
6073903cda
Co-authored-by: Christian Brabandt <cb@256bit.org>
