Problem: When the automatic regexp engine falls back to the
backtracking engine in vim_regexec_string(), the compiled
program is freed before the replacement is compiled; when
saving the pattern fails from being out of memory the
caller's "regprog" is left pointing to freed memory and
is freed again.
Solution: Free the previous program only after compiling the
replacement succeeded, like vim_regexec_multi() already
does (Samuel Schlesinger).
closes: vim/vim#20986cab0901f12
Co-authored-by: Samuel Schlesinger <sgschlesinger@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
- Mention unary +/- use in both integer and floating-point descriptions.
- Add "0b" binary prefix tag to match existing "0o" and "0x" tags.
closes: vim/vim#209976163d99a32
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
strace supports printing a complete stack trace for each syscall using
the `-k` (`--stack-trace`) flag. Highlight the trace as a comment.
closes: vim/vim#209982e8c81ea09
Co-authored-by: Josef Schönberger <josef.schoenberger@tum.de>
Now this was a cargo cult anti-pattern to write home about.
Doing painful save-and-restore bookkeeping around a separate
`magic_overruled` decoy global is just as messy as doing painful
save-and-restore logic around `p_magic` itself. only that now you need
to wrap every access to the effective value in a function call.
This replaces this with a marvellous new Clean Code technique™:
passing in the intended behavior as a function parameter to functions
where either the option or an explicit value might be used.
Problem:
A mark moved by nvim_buf_set_extmark() during an edit is misplaced by
undo and redo. Only splices ("edits") are recorded, and replaying them
reproduces the shifts they caused, never the explicit set: the mark ends
up wherever the text pushed it.
Solution:
When an open undo block moves an existing mark, record both positions.
Undo restores the pre-set position, redo re-applies the set.
Partially reverts 18334a4a0c ; ExtmarkSavePos.row/col were unused
because nothing recorded an explicit move, but now `extmark_set()` does.
Problem:
After #40270, events are no longer emitted from the automatic background
detection. This applies not just during startup, but also if the user
manually changes the background of their terminal.
Solution:
Set the background as normal, assuming that a normal terminal will
respond within 100 ms. Change test to match expected behavior:
- BG set during startup won't trigger user autocmds since it runs before
any user config
- If the terminal takes longer than 100 ms to respond to initial OSC 11,
it does trigger the OptionSet, but it is triggered through the normal
path to ensure values like v:option_new are set #38551
- BG change after startup still triggers autocmds #41146
vim-patch:8.2.1300: Vim9: optional argument type not parsed properly
vim-patch:8.2.1341: build failures
vim-patch:8.2.1551: Vim9: error for argument type does not mention the number
vim-patch:8.2.2630: hard to see where a test gets stuck
vim-patch:8.2.4350: FEAT_GUI_ENABLED defined but never used
vim-patch:9.0.2085: Vim9: abstract can be used in interface
vim-patch:9.1.1037: Vim9: confusing error when using abstract method via super
vim-patch:9.1.1586: Vim9: can define an enum/interface in a function
vim-patch:9.1.2076: tests: MinGW test fails midway and stops
vim-patch:9.2.0922: Wayland: modeless selection not redrawn
vim-patch:a6be0d496 CI: Add Github runner for Cygwin
vim-patch:9.2.0924: tests: Test_termwinscroll() fails on FreeBSD
vim-patch:081786261 CI: Bump github/codeql-action
vim-patch:8.1.1851: crash when sound_playfile() callback plays sound
vim-patch:8.2.1527: Vim9: cannot use a function name at script level
vim-patch:8.2.1541: Vim9: cannot find function reference for s:Func
vim-patch:8.2.1581: using line() for global popup window doesn't work
vim-patch:8.2.1582: the channel log does not show typed text
vim-patch:8.2.1592: Vim9: passing "true" to char2nr() fails
vim-patch:9.1.0879: source is not consistently formatted
Vim core did not leverage it to override/customize bell/beep.
It wasn't used for custom sounds for system/user (autocmd) events.
It should be in-scope for GUI, unlike terminal, even as a plugin
by leveraging some internal option similar to `set guioptions+=!`.
No progress as of Vim 9.2 so I quit.
vim-patch.sh fails to detect n/a patches
because of ifdef FEAT_ guards and reserved Vim9script error codes.
Ignore all conditional directives for Vim's "FEAT_" guards.
https://cppreference.com/c/preprocessor/conditional
Problem: Vim9: can't use v:true for option flags.
Solution: Add tv_get_bool_chk(). (closesvim/vim#6725)
----
"tv_get_bool_or_number_chk()" without vim9 params is identical to
"tv_get_number_chk()".
"tv_get_number_chk()" and tv"_get_bool_chk()" are identical
after excluding new vim9 params.
Yes, "want_bool" param is N/A because of "in_vim9script()".
If I port it, then I will refactor these macros or "static inline"
functions within "src/nvim/eval/typval.h".
----
36967b32fd
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: DocBook syntax variable scopes of docbk_type and docbk_ver
are not clearly documented: docbk_type uses the wrong scope
(it should be buffer-local) and docbk_ver also has an
undocumented buffer-local version.
Solution: Correct the docbk_type examples and describe the docbk_ver
precedence.
closes: vim/vim#20977e0b81136c7
Co-authored-by: Bogdan Barbu <l4b.bogdan.barbu@gmail.com>
Problem: Vim9: hasmapto(), mapcheck() and maparg() do not take "true" as
argument.
Solution: Use tv_get_bool(). (closesvim/vim#6822, closesvim/vim#6824)
04d594b9c1
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: index() does not take "true" as argument.
Solution: Use tv_get_bool_chk(). (closesvim/vim#6823)
6c553f9c04
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: getreg() does not take "true" as argument.
Solution: Use tv_get_bool_chk(). (closesvim/vim#6820)
67ff97ded7
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: expand() does not take "true" as argument.
Solution: Use tv_get_bool_chk(). (closesvim/vim#6819)
551d25e765
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Crash when getcompletiontype()/getcompletion() gets a NULL string
(dvaave2025).
Solution: Do not write the NUL terminator in set_cmd_context() when the
cursor column is at or past the end of the string, since the
string may be a read-only literal.
fixes: vim/vim#20963closes: vim/vim#20964
Supported by AI.
e2dcefa0d8
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Closing the current tab page resets the alternate tab page, even
when that is another tab page which still exists, so that
CTRL-Tab stops working (igorlfs).
Solution: Restore the last used tab page after entering another one to
close the current one (Hirohito Higashi).
related: vim/vim#20965
closes: vim/vim#20973a05bd64c1d
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
FAILED …/terminal/ex_terminal_spec.lua @ 270: :terminal (fake shell) spawns in CWD effective at time of invocation
Expected values to differ.
Value:
"~/work/neovim/neovim/build/Xtest_xdg_terminal"
stack traceback:
…/terminal/ex_terminal_spec.lua:276: in function <…/terminal/ex_terminal_spec.lua:270>
Problem:
The insert-mode completion progress-message is in "running" state while
the user is selecting an item. That is noisy and unwanted UX; it was
only intended for the "Scanning..." task.
Solution:
End the progress-msg just after `ins_compl_show_statusmsg`.
Problem:
Some builtin features emit progress-messages which never "complete".
- On failure, `:write` does not complete the progress-msg it started.
- ins-completion never ends its "Scanning..." message.
Solution:
- `buf_write()` emits "failed" status on failure.
- `ins_compl_stop()` ends the completion one.
Problem: Vim9: error when passing getreginfo() result to setreg().
Solution: Use dict_get_bool() for "isunnamed". (closesvim/vim#6784)
6a950581da
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: bufname('%') gives an error.
Solution: Only give an error for wrong argument type. (closesvim/vim#6807)
02aaad9109
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem:
filemess() treats an empty suffix as "a buffer write is starting", but
readfile() calls it that way too. So ":read" (and ":edit", …) opens a
`nvim.bufwrite "<file>"` progress that is never completed.
Users of e.g. ghostty will see a stuck "progress" spinner.
Solution:
Only `buf_write()` starts the progress, via `filemess_progress()`.
Problem:
:bcd (buffer-local directory) is not preserved after
`nvim_open_win` or `nvim_win_set_buf`
Analysis:
set_curbuf() ends with update_cwd(), which falls back to
os_chdir(globaldir) when the target buffer has no b_localdir.
Solution:
Pass kCtxKeepCwd to ctx_switch().
Problem: The reuse_client predicate does not pass the target buffer,
preventing decisions from being truly made per buffer.
Solution: Pass the target buffer.
