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.
The system version of ConPTY in kernel32.dll is old and will
mangle some VT sequences sent by shells. Newer versions of ConPTY
available as part of the Windows Terminal project fix this by
passing through VT sequences unmodified when the terminal has set
ENABLE_VIRTUAL_TERMINAL_INPUT. This change allows users to fix
buggy behaviour of Neovim's terminal on Windows by copying
conpty.dll to Neovim's bin directory.
Co-authored-by: Scott Young <s@sjy.au>
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.
Normalize the 15 existing guards to the documented two-level form
get(g:, 'X_recommended_style', get(g:, 'filetype_recommended_style', 1)):
fix the two non-standard "!exists() || != 0" guards (python, arduino) and
tolk's wrong fallback variable, and convert the simple one-level guards.
Add the guard to filetype plugins that set stylistic indentation/format
options without one: aap, abap, ada, cabal, cobol, elixir, falcon,
graphql, heex, idris2, mermaid, occam, racket, scala, swift, tera.
Settings that are required rather than stylistic are left untouched, e.g.
make/gomod/scdoc (mandatory tabs), chatito and vroom (indent mandated by
the format), and the textwidth/formatoptions cases in gitcommit/help/
jjdescription.
Supported by AI.
fixes: vim/vim#20036closes: vim/vim#206501f33732613
Co-authored-by: Christian Brabandt <cb@256bit.org>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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: Several string and memory wrapper macros cast their size
argument to size_t although the wrapped function's prototype
already declares that parameter size_t; such casts silence the
warning a compiler would otherwise give when a value of the
wrong type, such as a pointer, is passed as the size.
Solution: Where the wrapped function's prototype already declares the
parameter size_t, remove the cast so that a size argument of
the wrong type can be reported at compile time (K.Takata,
Shane Harper).
From gcc 14 on, -Wint-conversion is an error by default.
With gcc, passing a signed value where size_t is expected triggers
-Wsign-conversion, but the check is off by default and the build already
emits many such warnings.
related: vim/vim#20642
closes: vim/vim#206567f122f9eff
Co-authored-by: Shane Harper <shane@shaneharper.net>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
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.
socketserver.c is not compatible with Neovim's server implementation.
cairo, kitty, sixel, and similar backends for image rendering in popup
are not required in Neovim's C core.
Neovim can do this and even run Doom.
See patch 9.2.0612.
The following let-heredoc can cause legacy scripts to be misidentified
as Vim9 script if it appears early in the file. Only match :vim9script
at the start of a line where it sensibly belongs.
let x =<< trim LINES
vim9script
...
LINES
fixes: vim/vim#20647 (reported by Maxim Kim).
closes: vim/vim#206549a899af7e8
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
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.
* refactor(autocmd): safely parse buflocal buffer numbers
Replace unsafe atoi with a robust integer conversion when extracting
the buffer number out of a "<buffer=123>" pattern in
aupat\_get\_buflocal\_nr.
This prevents potential silent integer overflows and ensures variables
fit safely within INT\_MAX boundaries before truncation.
* fix(autocmd): use getdigits_int to safely parse buffer numbers
* fix(autocmd): raise error for invalid buffer-local pattern values
When defining an autocommand, an invalid buffer-local pattern format
(such as `<buffer=foo>` or `<buffer=0>`) would previously fall through
silently and default to a generic `<buffer>` tag behavior.
Fix this regression by trapping invalid buffer numbers
early from `aupat_get_buflocal_nr()` and throwing a proper E680 error
to match Vim's runtime validation behavior.
Problem: due to totally async install/update/checkout there is no
guaranteed order of `PackChanged{Pre,}` events across different
plugins. This might lead to conflicts when callback for some "main"
plugin relies on features from "dependency" plugin: i.e. callback for
"main" plugin can trigger before installing/updating "dependency"
plugin. The installation order can be enforced by separate
vim.pack.add() calls, but update/checkout can not.
Solution: Trigger events in bulk independently of async execution:
- `PackChangedPre` before any action for all input plugins in order
they are supplied. It will also trigger even if an action will fail.
- `PackChanged` after all actions finished for all sucessfully
affected plugins in order they are supplied.
This also comes with a couple of side effect changes:
- `PackChangedPre kind=delete` is now also triggered even if the
delete won't be done. This makes it more aligned with `kind=install`
and `kind=update`.
- Force update (`:packupdate!`) and "udpate LSP action" now do two
async steps: download/compute updates and apply them. This also
results in two progress reports.
This is mostly a by-product of the implementation (there has to be
a pre-computation of target revision for all plugins before doing
`PackChangedPre` in bulk before possibly applying an update), but I
kind of like it more this way as it is more explicit of what's going
on. If absolutely not acceptable, there might be some hacks to
mitigate it at least in code action, but I'd keep it like this.
Problem:
dir.lua leaves previously-navigated directory buffers around.
This is fine by default, but users need a simple way to opt out.
Solution:
1. Respect `set hidden` (via `'bufhidden'`) as one way to make
previously-navigated dir buffers from showing up.
2. Document a one-liner to hide these buffers
Problem: plugin/shada.lua does not respect the `+` flag of 'cpoptions'
when writing a *.shada buffer into a different file.
Solution: Check the presence of `+` in 'cpoptions' and whether the
buffer is written to a different file in BufWriteCmd for
*.shada before resetting the 'modified' option of the buffer.
This little defect appeared after plugin/shada.vim was rewritten into
Lua in #34725.
Problem: Separation markers (%=) are ignored within item groups. This
lead to a regression when the C implementation of the statusline was
replaced with a default expression. When the user configured a custom
ruler expression with a %= and used the overloaded item group syntax to
set the ruler width, the separation marker worked in the ruler, but not
when the ruler was incorporated into the statusline where the item group
syntax was interpreted in the usual way.
Solution: Analogously to top-level behaviour, expand separation markers
evenly within item groups until `minwid` is reached (if set).
ref https://github.com/neovim/neovim/pull/33036
fix https://github.com/neovim/neovim/issues/39984
ref https://github.com/neovim/neovim/issues/40247
Problem: The recursion offset into the static `stl_items` was not taken
into account when adjusting the item count after truncation.
Steps to reproduce: first prepare `stl_items`:
set stl=%{%repeat('%#Error#',10)%}
then watch how the Error highlight leaks into the recursive call:
set stl=%l%l%l%{%nvim_eval_statusline('test%l%<',{'maxwidth':3,'highlights':1}).highlights%}
ref https://github.com/neovim/neovim/issues/32259
* fix(statusline): consistent truncation at multicell character
Problem 1: truncation of item groups at multicell character didn't take
into account that minwid can be specified as a negative number.
Problem 2: after truncation at top-level from the right at multicell
character, the returned width was always `maxwidth`, even though the
actual width was reduced. In vim, this can be observed as a statusline
that is not fully drawn until the edge of the screen:
vim --clean +"set ls=2 stl=%{%repeat('x',&columns-2)%}🙂x%<"
Problem 3: after truncation at top-level from the left at multicell
character, the resulting gap to reach `maxwidth` again was filled with
fillchars, but then the final NUL was not set correctly.
This can be seen in the following example, where the statuscolumn spills
into the editing area starting from line 10:
nvim --clean +"set number stc=%<x🙂%{repeat('x',43)}%l" +"norm yy10p"
Solution: fix the small errors and, at top-level, consistently reduce
the size instead of compensating with fillchars. In the case of the
statusline and the winbar, the remaining place is filled with the
configured fillchars in `win_redr_custom`, after `build_stl_str_hl` has
returned. In all other cases (title, icon, statuscol, tabline, ruler),
there seems to be no point in adding additional spaces at the end.
* feat(statusline)!: scope %< to item groups
Problem:
Previously, item groups were only truncated at the beginning, which is
often not desired. In the example
%.15(path: %f%)
the group's title/label is truncated away:
<th/to/file.txt
Truncation markers (%<) in item groups were processed at the top-level
in the end, which can be confusing. Only the first %< is used for the
whole string, and it is used even if the containing item group is
hidden. Additionally, in the case of hidden item groups, the marker's
position was not adapted. For example,
%(hidden%<%)%f
had the effect of truncating the path somewhere in the middle:
/path/<file.txt
Solution:
Make truncation consistent with top-level behaviour, which has a better
default of truncating at the first `Normal` item, i.e.
path: <file.txt
and allows for fine-grained control with truncation markers (%<). E.g.
%.15(path: %f%<%)
now yields
path: /path/to>
The original behaviour can be restored like so:
%.15(%<path: %f%)
BREAKING CHANGE: %< is no longer processed at top-level
- the default truncation behaviour has changed: now at first item
- truncation markers inside item groups don't affect truncation outside
of the item group anymore
- several truncation markers can now have an effect when separated with
item groups, whereas previously only the first one globally had
ref https://github.com/neovim/neovim/issues/39984
Problem: LspNotify will fire for any attached client. If there's at
least two clients where one has semantic tokens enabled and one that
doesn't, the disabled one will get the LspNotify requests but won't have
a client state.
Solution: Only process LspNotify autocmds if there's a client state to
act on.
Fixes#40448
Problem: A crafted swap file can cause an out-of-bounds write during
recovery when the same block is referenced twice with
different pe_page_count values (cipher-creator)
Solution: Check hp->bh_page_count against page_count after mf_get() and
clamp page_count to the actual block size.
closes: vim/vim#2064543939cf9eb
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: With PHP omni-completion, a crafted file can potentially
execute arbitrary commands when completing a class member.
Solution: Quote the class name before inserting it into the search()
pattern run via win_execute().
43afc581a3
Tests only. The bug is not ported yet.
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Problem: [security]: With C omni-completion, a crafted tags file can execute
arbitrary Ex commands when completing a struct/union member
(cipher-creator)
Solution: Escape the type field before inserting it into the :vimgrep
pattern so it cannot close the pattern and start a new command
(Hirohito Higashi).
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-mf92-v4xw-j45x6b611b0d15
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Problem: The "%" command and bracket/text-object motions can skip the
matching paren or bracket on a line with quotes and a trailing
backslash.
Solution: Use the quote state at the search start when an odd-quote line
is continued with a backslash, instead of always treating the
search as starting in quotes (Barrett Ruth).
closes: vim/vim#20631c44a6561cc
Co-authored-by: Barrett Ruth <br@barrettruth.com>
Problem: ":filetype detect" is a valid command but not offered by
command-line completion.
Solution: Add "detect" to the completion candidates (glepnir)
closes: vim/vim#20625984f29860e
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: filetype: supertux info pattern is relative to current
directory (after 9.2.0716).
Solution: Add `*/` to the start of the pattern (zeertzjq)
closes: vim/vim#20629c30ee2efa9
