Problem: With 'wildmode' set to list:full, matches are listed but the
first match is not completed on the first Tab press (rendcrx).
Solution: Do not suppress selection when list and full are active in
the same completion phase. Add regression tests for file
completion, comma-separated phases and noselect precedence
(Seunghee Kim).
fixes: vim/vim#19532
related: vim/vim#18088
closes: vim/vim#2118154c988c6c5
Co-authored-by: SeungheeKim <ksh368@naver.com>
Problem: popup_show() from a CmdlineChanged autocommand doesn't update
the screen (Mao-Yining)
Solution: Refresh the screen when popups need redraw
(Yasuhiro Matsumoto).
popup_settext()/popup_show() called from a CmdlineChanged autocommand
did not refresh the screen because cmdline mode normally skips
update_screen(), so async info-popup updates only became visible after
a manual :redraw. Refresh the screen when popups need redrawing right
after the autocommand.
fixes: vim/vim#20175closes: vim/vim#20179ef1ecc3b61
Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
Other (squashed) commits:
fix(tui): emit ui_send output atomically with the frame
Problem:
tui_ui_send() writes directly to the TTY, bypassing the output buffer.
Sequences sent via nvim_ui_send() (e.g. kitty multiple-cursors, or
visual-dot-repeat) always arrive in a separate TTY write from the frame
they were computed for. This manifests as "tearing", or e.g. in the case
of multicursor the terminal renders text with stale cursor overlays.
Solution:
- tui_ui_send(): while a frame is being assembled (pending invalid
regions or buffered output), buffer instead of writing directly.
- Out-of-frame sends (tty queries, clear-on-disable) still write
immediately.
- mcursor.lua: emit the terminal-cursor update at the end of the redraw
cycle (`on_end`, when screen positions are final) instead of
vim.schedule().
Problem: options related to ui2 (like `fillchars` with `msgsep`) do not
take effect if set during startup after enabling ui2.
Solution: explicitly check just after startup if relevant options were
changed during startup.
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.
Problem:
Folding range markers are overwritten while ranges are evaluated. A range ending on a row can hide another range starting there, and multiple nested ranges ending together emit only the innermost ending level.
Solution:
Track starts and the number of ends per row before emitting markers. Prefer starts on shared boundary rows and use the outermost level when nested ranges end together.
AI-assisted
Problem:
Confirming cmdwin with a UTF-8 character containing 0x80 does not complete the
command.
Solution:
Escape K_SPECIAL bytes while feeding the cmdwin input after confirmation.
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: C keywords are matched using the characters from 'iskeyword',
so changing that option highlights part of an identifier as a
keyword and leaves keywords containing an underscore
unhighlighted.
Solution: Set the keyword characters with ":syn iskeyword".
fixes: vim/vim#21173closes: vim/vim#211765c9c5a43c1
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-Authored-By: Maxim Kim <habamax@gmail.com>
Problem: YAML syntax highlighting is slow; the yamlInteger and yamlFloat
rules alone account for over half of the parsing time.
Solution: The number, null and timestamp scalar patterns begin with a
lookbehind, which stops the regexp engine from using a
first-character search, so the automatic engine selects the
much slower NFA engine. Force the backtracking engine with
\%#=1 on these patterns for a large speedup with identical
matches (Jordan).
On a 40000-line YAML file the total :syntime drops by about 30%: the
yamlFloat rule goes from 0.61s to 0.17s and yamlInteger from 0.42s to 0.31s.
The engine override is applied only to the lookbehind-anchored number rules;
forcing it on the structural plain-scalar and mapping-key patterns regresses
them badly, so those are left on the automatic engine.
closes: vim/vim#21182560dfadac8
Co-authored-by: Julien Voisin <julien.voisin@dustri.org>
Problem:
The "." example mapping at `:h edit-repeat` doesn't work well with
`nvim_feedkeys(…, 'mt', false)`.
Solution:
Use `vim.b[ev.buf].maxseq` instead of `undotree()`.
Problem:
The cmdline_hide callback causes an unnecessary cursor move to the cmdline,
before the normal redraw updates the cursor back to the current window. This
appears as "flicker" when using plugins such as matchit (legacy ":" mappings
instead of "<cmd>" mappings).
Solution:
Skip the immediate redraw for cmdline_hide events. The normal redraw
still updates the cursor after the cmdline window is hidden.
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:
If a snippet does not have a placeholder, we use insert mode instead of
select mode. From here <Esc> leaves the session and highlight active.
Solution:
Cancel the session on <Esc>.
Problem:
0c091cedc2 fixed the "immediate exit" but the 2s `nvim_get_proc()`
check still fails on slow (ASAN) CI.
Solution:
Check the pid after the `screen:expect`. Anyway, `assert_nolog` is the
"meaningful" part of the test since 0c091cedc2.
Problem: `gettext` and `libiconv` are hosted on a single FTP server
which can be flaky. Since this impacts CI, we mirror them at
neovim/deps, but that creates maintainer friction.
Solution: Since the Zig build is tied to the upstream server anyway (via
allyourcodebase/libiconv) and most other platforms do not build the
bundled versions, just use the upstream server for CMake as well.
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.
Problem: Unlike CMake, `build.zig` downloads and builds GNU libiconv
on macOS instead of linking to the system framework.
Solution: Only pull in the libiconv dependency on Windows and link
against system framework on macOS.
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:
When 'cmdheight' is 0, the MsgSeparator can obscure the statusline when
a message is displayed, making its contents disappear until
the next redraw.
Solution:
Skip the separator when 'cmdheight=0' available.
Problem:
A blank line before the Content-Length header makes header parsing
fail with "Content-Length not found in header". An LF in the 'name'
state falls through to the 'invalid' state, which only return to
'name' at the *next* LF. That LF terminates the next line, so the
line with Content-Length is swallowed.
The same issue happens when a junk line is a partial match of the
header name (e.g. "Cont\nContent-Length: ...").
Solution:
When seeing an LF in the 'name' state, reset the cursor and stay in
'name' rather than entering 'invalid'.
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.
