patch 9.1.1616: xxd: possible buffer overflow with bitwise output
Problem: xxd: possible buffer overflow with bitwise output
(after v9.1.1459, Xudong Cao)
Solution: Update LLEN_NO_COLOR macro definition for the max line output
(using bitwise output -b)
Problem: diff format erroneously detected
(Tomáš Janoušek)
Solution: Make the regex to detect normal diff format a bit stricter,
while at it, fix wrong test content from patch v9.1.1606
patch 9.1.1612: Ctrl-G/Ctrl-T do not ignore the end search delimiter
Problem: Ctrl-G/Ctrl-T does not ignore the end search delimiter
(irisjae)
Solution: Check if the pattern ends with a search delimiter and ignore
it, unless it is part of the pattern.
Áron Hárnási [Sat, 9 Aug 2025 21:43:13 +0000 (23:43 +0200)]
patch 9.1.1611: possible undefined behaviour in mb_decompose()
Problem: possible undefined behaviour in mb_decompose(), when using the
same pointer as argument several times
Solution: use separate assignments to avoid reading and writing the same
object at the same time (Áron Hárnási)
closes: #17953
Signed-off-by: Áron Hárnási <aron.harnasi@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
- Match &option, and &[lg]:option variables.
- Match Ex commands after :bar.
- Fix matching of pre and post context text.
- Style - use '..' for string concatenation.
fixes #17567
closes: #17653
Signed-off-by: Doug Kearns <dougkearns@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
D. Ben Knoble [Sat, 9 Aug 2025 21:38:07 +0000 (23:38 +0200)]
runtime(racket): update Racket runtime files
This brings the upstream files to commit 9dc3bd3 (ftplugin: escape Vim
special characters when opening docs, 2025-08-09). Note that not all
upstream files are included.
closes: #17956
Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
zeertzjq [Fri, 8 Aug 2025 14:03:43 +0000 (16:03 +0200)]
patch 9.1.1610: completion: hang or E684 when 'tagfunc' calls complete()
Problem: completion: hang (after 9.1.1471) or E684 (after 9.1.1410)
when 'tagfunc' calls complete().
Solution: Check if complete() has been called immediately after getting
matches instead of in the next loop iteration (zeertzjq).
patch 9.1.1607: :apple command detected as :append
Problem: :apple command detected as :append (dai475694450)
Solution: Disallow to define a custom command with lower-case letter,
correctly detect :insert/:change/:append ex commands
(Hirohito Higashi).
fixes: #17893
closes: #17930
Signed-off-by: Hirohito Higashi <h.east.727@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Girish Palya [Fri, 8 Aug 2025 10:42:10 +0000 (12:42 +0200)]
patch 9.1.1604: completion: incsearch highlight might be lost
Problem: completion: incsearch highlight might be lost after search
completion (Hirohito Higashi)
Solution: Restore incsearch highlight after dismissing pum with Ctrl-E
(Girish Palya)
RestorerZ [Fri, 8 Aug 2025 10:37:06 +0000 (12:37 +0200)]
runtime(optwin): Fix E94 when searching for the option-window
Problem: When the parameter debug=msg is set and the command :option is
entered, error E94 will be displayed.
Solution: Add a check for the existence of the buffer before getting the
buffer number “option-window”.
Reproduce:
vim --clean -c "set debug=msg" -c "option"
Error detected while processing command line..script D:\Programs\Vim\vim91\optwin.vim:
line 9: E94: No matching buffer for option-window
closes: #17927
Signed-off-by: RestorerZ <restorer@mail2k.ru> Signed-off-by: Christian Brabandt <cb@256bit.org>
runtime(java): Manage byte limits for variable-width lookbehind assertions
Raise the byte limits from 80 to 120 for "javaFuncDef" and
"java*CommentTitle"; and support selecting other arbitrary
values with
------------------------------------------------------------
let g:java_lookbehind_byte_counts = {
\ 'javaMarkdownCommentTitle': 240,
\ }
------------------------------------------------------------
for related groups of syntax definitions, referring to their
names with dictionary keys.
Phạm Bình An [Fri, 8 Aug 2025 08:44:18 +0000 (10:44 +0200)]
runtime(help): Unset `'comments'` and `'cms'` options
Problem: Vim's help file doesn't have any syntax for comments, but
'comments' and 'commentstring' are still set in the help
buffer.
Solution: Unset 'comments' and 'cms' in help buffer
closes: #17889
Signed-off-by: Phạm Bình An <111893501+brianhuster@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1600: using diff anchors with hidden buffers fails silently
Problem: diff: using diff anchors with hidden buffers fails silently
Solution: Give specific error message for diff anchors when using hidden
buffers (Yee Cheng Chin).
Diff anchors currently will fail to parse if a buffer used for diff'ing
is hidden. Previously it would just fail as the code assumes it would
not happen normally, but this is actually possible to do if `closeoff`
and `hideoff` are not set in diffopt. Git's default diff tool "vimdiff3"
also takes advantage of this.
This fix this properly would require the `{address}` parser to be
smarter about whether a particular address relies on window position or
not (e.g. the `'.` address requires an active window, but `'a` or `1234`
do not). Since hidden diff buffers seem relatively niche, just provide a
better error message / documentation for now. This could be improved
later if there's a demand for it.
related: #17615
closes: #17904
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
zeertzjq [Thu, 7 Aug 2025 13:24:29 +0000 (15:24 +0200)]
patch 9.1.1599: :bnext doesn't go to unlisted help buffers
Problem: :bnext doesn't go to unlisted help buffers when cycling
through help buffers (after 9.1.0557).
Solution: Don't check if a help buffer is listed (zeertzjq).
From <https://github.com/vim/vim/issues/4478#issuecomment-498831057>:
> I think we should fix that, since once you get to a non-help buffer
> all unlisted buffers are skipped, thus you won't encounter another
> help buffer.
This implies that cycling through help buffers should work even if help
buffers are unlisted. Otherwise this part of :bnext isn't really useful,
as :h makes help buffers unlisted by default.
related: #4478
related: #15198
closes: #17913
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1597: CI reports leaks in libgtk3 library
Problem: CI reports leaks in libgtk3 library
Solution: Add libgtk-3 library to leak suppression
Recently, CI started reporting leaks inside the GTK3 library, which cause
failures like here
https://github.com/vim/vim/actions/runs/16796766276/job/47572520887?pr=17922
So let's add libgtk-3*.so* to the leak suppression for the
gtk_init_check() function.
zeertzjq [Thu, 7 Aug 2025 12:57:22 +0000 (14:57 +0200)]
patch 9.1.1596: tests: Test_search_wildmenu_iminsert() depends on help file
Problem: tests: Test_search_wildmenu_iminsert() depends on help file
(after 9.1.1594).
Solution: Set buffer text using setline() instead of loading help file.
Add a test for another bug fixed by 9.1.1594 (zeertzjq).
related: #17870
closes: #17922
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
runtime(syntax-tests): Break up non-ASCII over-75-byte-long lines
And anticipate occasional multibyte line wrapping owing to:
> A poorly rendered line may otherwise become wrapped when enough of
> spurious U+FFFD (0xEF 0xBF 0xBD) characters claim more columns than
> are available (75) and then invalidate line correspondence under test.
Observe that for "vim_ex_command.vim" another workaround is
chosen: the long line containing an only multibyte character
near its EOL is conversely made longer by padding and moving
the character to a separate _tail_ part of the wrapped line.
That is, the _head_ part of the line is all ASCII characters
and the wrapped _tail_ part is a mix of various characters
whose total byte count is within bounds.
Other unmodified tracked files of interest:
java_lambda_expressions.java,
java_lambda_expressions_signature.java,
java_numbers.java,
markdown_conceal.markdown,
vim9_generic_function_example_set.vim
patch 9.1.1592: Vim9: crash with classes and garbage collection
Problem: Vim9: crash with classes and garbage collection
(Christian J. Robinson, after v9.1.1566)
Solution: When getting the references to an object, make sure the object
is valid (Yegappan Lakshmanan)
closes: #17860
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
As reported in #16559, bytes of a multibyte character may
be written as separate U+FFFD characters in a ":terminal"
window on a busy machine. The testing facilities currently
offer an optional filtering step to be carried out between
reading and comparing the contents of two screendump files
for each such file. This filtering has been resorted to
(#14767 and #16560) in an attempt to unconditionally replace
known non-Latin-1 characters with an arbitrary substitute
ASCII character and avoid this rendering mishap leading to
syntax tests failures. However, it has been overlooked at
the time that metadata description (in shorthand) to follow
spurious U+FFFD characters may be *distinct* and make the
remainder of such a line, ASCII characters and whatnot, also
unequal between compared screendump files.
While it is straightforward to adapt current filter files to
ignore the line characters after the leftmost U+FFFD,
> It is challenging and error-prone to keep up to date filter
> files because moving around examples in source files will
> likely make redundant some previously required filter files
> and, at the same time, it may require creating new filter
> files for the same source file; substituting one multibyte
> character for another multibyte character will also demand
> a coordinated change for filter files.
Besides, unconditionally dropping arbitrary parts of a line
is rather too blunt an instrument. An alternative approach
is to not use the supported filtering for this purpose; let
a syntax test pass or fail initially; then *if* the same
failure is imminent, drop the leftmost U+FFFD and the rest
of the previously seen line (repeating it for all previously
seen unequal lines) before another round of file contents
comparing. The obvious disadvantage with this filtering,
unconditional and otherwise, is that if there are consistent
failures for _other reasons_ and the unequal parts happen to
be after U+FFFDs, then spurious test passing can happen when
stars align for _a particular test runner_.
Hence syntax test authors should strive to write as little
significant text after multibyte characters as syntactically
permissible, write multibyte characters closer to EOL in
general, and make sure that their checked-in and published
"*.dump" files do not have any U+FFFDs.
It is also practical to refrain from attempting screendump
generation if U+FFFDs can already be discovered, and instead
try re-running from scratch the syntax test in hand, while
accepting other recently generated screendumps without going
through with new rounds of verification.
CI(screendump): Support iterative filtering for screendump comparison
Before two screendumps are compared for equality by calling
"VerifyScreenDump()", parts of their contents can be omitted
from comparison by executing arbitrary Vim commands written
in a filter file that shares its basename with screendumps.
Sometimes, such filtering can only be too general, as more
context is required in order to decide what parts to touch.
Two new arbitrary functions are therefore hooked in the body
of "VerifyScreenDump()" for the purpose of probing into the
current context and applying iterative filtering as needed.
A paired-up public implementation of each function is also
provided to expedite a workaround for #16559:
------------------------------------------------------------
source util/screendump.vim
let opts = {
\ 'FileComparisonPreAction':
\ function('g:ScreenDumpDiscardFFFDChars'),
\ 'NonEqualLineComparisonPostAction':
\ function('g:ScreenDumpLookForFFFDChars'),
\ }
call g:VerifyScreenDump(buf, basename, opts)
------------------------------------------------------------
related: #17704
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
CI: Include provenance in names of collected artifacts
The currently given names to the uploaded archives are too
common and require (often manual) renaming for downloaded
archives that belong to different CI runs/attempts of a PR
and/or different PRs. Let's automatically disambiguate such
archives from one another by giving them more unique names
for convenience and future reference.
related: #17704
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: VMS support can be improved
Solution: Merge chagnes from Steven M. Schweda
(Zoltan)
closes: #17810
Co-authored-by: Steven M. Schweda <sms@antinode.info> Signed-off-by: Zoltan Arpadffy <zoltan.arpadffy@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: cannot perform autocompletion
Solution: Add the 'autocomplete' option value
(Girish Palya)
This change introduces the 'autocomplete' ('ac') boolean option to
enable automatic popup menu completion during insert mode. When enabled,
Vim shows a completion menu as you type, similar to pressing |i\_CTRL-N|
manually. The items are collected from sources defined in the
'complete' option.
To ensure responsiveness, this feature uses a time-sliced strategy:
- Sources earlier in the 'complete' list are given more time.
- If a source exceeds its allocated timeout, it is interrupted.
- The next source is then started with a reduced timeout (exponentially
decayed).
- A small minimum ensures every source still gets a brief chance to
contribute.
The feature is fully compatible with other |i_CTRL-X| completion modes,
which can temporarily suspend automatic completion when triggered.
See :help 'autocomplete' and :help ins-autocompletion for more details.
To try it out, use :set ac
You should see a popup menu appear automatically with suggestions. This
works seamlessly across:
- Large files (multi-gigabyte size)
- Massive codebases (:argadd thousands of .c or .h files)
- Large dictionaries via the `k` option
- Slow or blocking LSP servers or user-defined 'completefunc'
Despite potential slowness in sources, the menu remains fast,
responsive, and useful.
Compatibility: This mode is fully compatible with existing completion
methods. You can still invoke any CTRL-X based completion (e.g.,
CTRL-X CTRL-F for filenames) at any time (CTRL-X temporarily
suspends 'autocomplete'). To specifically use i_CTRL-N, dismiss the
current popup by pressing CTRL-E first.
---
How it works
To keep completion snappy under all conditions, autocompletion uses a
decaying time-sliced algorithm:
- Starts with an initial timeout (80ms).
- If a source does not complete within the timeout, it's interrupted and
the timeout is halved for the next source.
- This continues recursively until a minimum timeout (5ms) is reached.
- All sources are given a chance, but slower ones are de-prioritized
quickly.
Most of the time, matches are computed well within the initial window.
---
Implementation details
- Completion logic is mostly triggered in `edit.c` and handled in
insexpand.c.
- Uses existing inc_compl_check_keys() mechanism, so no new polling
hooks are needed.
- The completion system already checks for user input periodically; it
now also checks for timer expiry.
---
Design notes
- The menu doesn't continuously update after it's shown to prevent
visual distraction (due to resizing) and ensure the internal list
stays synchronized with the displayed menu.
- The 'complete' option determines priority—sources listed earlier get
more time.
- The exponential time-decay mechanism prevents indefinite collection,
contributing to low CPU usage and a minimal memory footprint.
- Timeout values are intentionally not configurable—this system is
optimized to "just work" out of the box. If autocompletion feels slow,
it typically indicates a deeper performance bottleneck (e.g., a slow
custom function not using `complete_check()`) rather than a
configuration issue.
---
Performance
Based on testing, the total roundtrip time for completion is generally
under 200ms. For common usage, it often responds in under 50ms on an
average laptop, which falls within the "feels instantaneous" category
(sub-100ms) for perceived user experience.
| Upper Bound (ms) | Perceived UX
|----------------- |-------------
| <100 ms | Excellent; instantaneous
| <200 ms | Good; snappy
| >300 ms | Noticeable lag
| >500 ms | Sluggish/Broken
---
Why this belongs in core:
- Minimal and focused implementation, tightly integrated with existing
Insert-mode completion logic.
- Zero reliance on autocommands and external scripting.
- Makes full use of Vim’s highly composable 'complete' infrastructure
while avoiding the complexity of plugin-based solutions.
- Gives users C native autocompletion with excellent responsiveness and
no configuration overhead.
- Adds a key UX functionality in a simple, performant, and Vim-like way.
closes: #17812
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1589: Cannot disable cscope interface using configure
Problem: Cannot disable cscope interface using configure, because in
feature.h FEAT_CSCOPE will always be enabled for huge builds
(chdiza)
Solution: Don't define FEAT_CSCOPE from configure script but set the
ENABLE_CSCOPE flag and check for the presence of that flag in
feature.h
patch 9.1.1586: Vim9: can define an enum/interface in a function
Problem: Vim9: can define an enum/interface in a function
(lacygoill)
Solution: Give an error when defining an enum or an interface inside a
function (Yegappan Lakshmanan)
fixes: #17835
fixes: #17837
closes: #17837
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1585: Wayland: gvim still needs GVIM_ENABLE_WAYLAND
Problem: Wayland: gvim still needs GVIM_ENABLE_WAYLAND
Solution: Drop the GVIM_ENABLE_WAYLAND code, always enable both X11 and
Wayland GUI support (Christoffer Aasted)
closes: #17817
Signed-off-by: Christoffer Aasted <chr.aasted@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
runtime(misc): use :hor :term to ensure new term window is split horizontally
Problem: :term splits new window above in vim, but in nvim it change
the buffer for current window
Solution: :hor term to ensure consistent splitting for Vim and Neovim
closes: #17822
Signed-off-by: phanium <91544758+phanen@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Olaf Seibert [Wed, 23 Jul 2025 17:35:59 +0000 (19:35 +0200)]
patch 9.1.1583: gvim window lost its icons
Problem: Since patch 9.1.1199 the gvim window no longer had _NET_WM_ICON
nor WM_HINTS icon information, for example when not using a
Gnome or KDE desktop (after v9.1.1199)
Solution: Check if the icon theme as used in patch 1199 contains a gvim
icon. If so, set the window's icon from that. Otherwise
use the previous method (Olaf Seibert)
fixes: #17703
closes: #17814
Signed-off-by: Olaf Seibert <rhialto@falu.nl> Signed-off-by: Christian Brabandt <cb@256bit.org>
Lidong Yan [Tue, 22 Jul 2025 16:15:57 +0000 (18:15 +0200)]
patch 9.1.1581: possible memory leak in vim9generics.c
Problem: possible memory leak in vim9generics.c
Solution: Free ret_free if ga_grow() fails and before returning
(Lidong Yan).
In parse_generic_func_type_args() at vim9generics.c, we allocate memory
in ret_name and should free it by calling vim_free(ret_free). If
ga_grow on gfatab->gfat_args failed, we forget to call vim_free(ret_free)
thus would cause a leak. Add vim_free(ret_free) before return NULL.
closes: #17821
Signed-off-by: Lidong Yan <yldhome2d2@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Lidong Yan [Tue, 22 Jul 2025 16:11:11 +0000 (18:11 +0200)]
patch 9.1.1580: possible memory leak in vim9type.c
Problem: possible memory leak in vim9type.c
Solution: Free tuple_types_ga if there was an error in
type_type_add_types() (Lidong Yan)
In parse_type_tuple() at src/vim9type.c, we allocate memory
in `tuple_types_ga` by ga_grow(), but forget to free it when
tuple_type_add_types() fails. Replace `return NULL` with `goto on_err`
to fix leak.
closes: #17820
Signed-off-by: Lidong Yan <yldhome2d2@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1579: Coverity complains about unchecked return value
Problem: Coverity complains about unchecked return value in
common_function() (after v9.1.1577)
Solution: Check the return value of skip_generic_func_type_args()
and return in case of an error (Yegappan Lakshmanan)
closes: #17818
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1578: configure: comment still mentions autoconf 2.71
Problem: configure: comment still mentions autoconf 2.71 to generate
the configure script
Solution: Update the comment to use autoconf 2.72 instead (Yee Chin Cheng).
Vim v9.1.1369 updated the autoconf generation to be done using 2.72.
Update comments to reflect that.
closes: #17815
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
This PR introduces a new `wildtrigger()` function.
See `:h wildtrigger()`
`wildtrigger()` behaves like pressing the `wildchar,` but provides a
more refined and controlled completion experience:
- Suppresses beeps when no matches are found.
- Avoids displaying irrelevant completions (like full command lists)
when the prefix is insufficient or doesn't match.
- Skips completion if the typeahead buffer has pending input or if a
wildmenu is already active.
- Does not print "..." before completion.
This is an improvement on the `feedkeys()` based autocompletion script
given in #16759.
projects / thirdparty / vim.git / log
