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.
patch 9.1.1575: tabpanel not drawn correctly with wrapped lines
Problem: tabpanel not drawn correctly with wrapped lines
(utubo, after v9.1.1534)
Solution: Use Columns as width, not the frame width
(Hirohito Higashi)
fixes: #17774
closes: #17809
Signed-off-by: Hirohito Higashi <h.east.727@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Dead code in mbyte.c
Solution: Delete the dead wcwidth()/iswprint() code
(Damien Lejay)
These library calls have been disabled since patch 6.2.446 (2002) due to
display issues with Hebrew. They are also non-portable: wcwidth() is a
POSIX function and not available on MSVC or other non-POSIX platforms.
Keeping this code path adds complexity without benefit.
closes: #17811
Signed-off-by: Damien Lejay <damien@lejay.be> Signed-off-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
```
does not seem to be solving the problem. It only hides the
`POT-Creation` line from the `vim.pot` diff. Maybe a more elaborate
filter could be used - one that replaces lines numbers in `vim.pot` with
`xxxx`, thus removing the most annoying and useless part of the diff.
One downside is that it requires everyone to install such a filter
locally - it can not be part of the repo config, as far as I understand.
closes: #17775
Signed-off-by: Illia Bobyr <illia.bobyr@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
translation: do not add message location as comments into vim.pot
Let's add the --no-location to the xgettext command line call, so that
the generated vim.pot file does not contain the message location. Those
will get out of date soon and we don't want to update vim.pot just
because the location in a comment changes.
Problem: The CmdlineChanged event was firing unnecessarily, even when
the command line's content hadn't actually changed.
Solution: I've added a check to compare the command-line buffer's state
before and after key processing. The `CmdlineChanged` event
now only triggers if the buffer's contents are genuinely
different (Girish Palya).
closes: #17803
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: tests: Vim9 tests can be improved
Solution: In Test_has_func_shortcircuit(), move the test functions to a
separate script (Yegappan Lakshmanan)
closes: #17796
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Crash when using inline diff mode
(Ilya Grigoriev)
Solution: Set tp_diffbuf to NULL when skipping a diff block
(Yee Cheng Chin).
Fix an array out of bounds crash when using diffopt+=inline:char when 4
or more buffers are being diff'ed. This happens when one of the blocks
is empty. The inline highlight logic skips using that buffer's block,
but when another buffer is used later and calls diff_read() to merge the
diff blocks together, it could erroneously consider the empty block's
diff info which has not been initialized, leaving to diff numbers that
are invalid. Later on the diff num is used without bounds checking which
leads to the crash.
Fix this by making sure to unset tp_diffbuf to NULL when we skip a
block, so diff_read() will not consider this buffer to be used within
inline diff. Also, add more bounds checking just to be safe.
closes: #17805
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Sean Dewar [Fri, 18 Jul 2025 18:09:47 +0000 (20:09 +0200)]
patch 9.1.1564: crash when opening popup to closing buffer
Problem: Can open a popup window to a closing buffer, leading to the
buffer remaining open in the window after it's soon unloaded,
causing crashes.
Solution: Check b_locked_split when opening a popup window to an
existing buffer (Sean Dewar).
closes: #17790
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
translation: mark vim.pot as linguist-generated, ignore msg locations in vim.pot
Update the textconv filter to filter out changes in the comments
pointing to the location of the message.
Also remove the comments in vim.pot that mention the message location.
Since those will be ignored using vims textconv filter, it does not make
sense to keep them, they would get out of sync anyhow.
closes: #17782
Co-authored-by: Illia Bobyr <illia.bobyr@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: The ruler disappears after typing the second character during
insert mode completion, even when completion messages are
suppressed ('shortmess' includes "c"). This makes the UI
appear inconsistent.
Solution: Ensure the ruler is restored during screen redraw when popup
completion is active (Girish Palya).
Notes:
No new tests were added, as existing screen dump tests were updated to
reflect the corrected behavior.
closes: #17770
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1562: close button always visible in the 'tabline'
Problem: close button "X" is visible in the non-GUI 'tabline', even
when the mouse is disabled
Solution: only show the button when 'mouse' contains any of the flags
"anvi" (Girish Palya)
The tabline always displays an "X" (close) button, and the info popup
shows both a close button and a resize handle—even when the mouse is
disabled. These UI elements are only actionable with the mouse and serve
no purpose for keyboard users who disable the mouse. Displaying
non-functional, clickable elements in a non-GUI environment is
misleading and adds unnecessary visual clutter.
So remove the close button and resize handle when the mouse is disabled.
They appear again when mouse is enabled.
closes: #17765
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1559: tests: Test_popup_complete_info_01() fails when run alone
Problem: tests: Test_popup_complete_info_01() fails when run alone.
Solution: Set buffer-local competeopt+=noinsert and add missing cleanup
in Test_popup_complete() (zeertzjq).
closes: #17773
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Regenerate vim.pot because of a wording update in optwin.vim for the
diffanchors feature.
While at it, update the textconv filter to ignore all lines
containing version.c because those change just by incrementing
the Vim patch number *grummel*
patch 9.1.1557: not possible to anchor specific lines in difff mode
Problem: not possible to anchor specific lines in difff mode
Solution: Add support for the anchoring lines in diff mode using the
'diffanchor' option (Yee Cheng Chin).
Adds support for anchoring specific lines to each other while viewing a
diff. While lines are anchored, they are guaranteed to be aligned to
each other in a diff view, allowing the user to control and inform the
diff algorithm what the desired alignment is. Internally, this is done
by splitting up the buffer at each anchor and run the diff algorithm on
each split section separately, and then merge the results back for a
logically consistent diff result.
To do this, add a new "diffanchors" option that takes a list of
`{address}`, and a new "diffopt" option value "anchor". Each address
specified will be an anchor, and the user can choose to use any type of
address, including marks, line numbers, or pattern search. Anchors are
sorted by line number in each file, and it's possible to have multiple
anchors on the same line (this is useful when doing multi-buffer diff).
Update documentation to provide examples.
This is similar to Git diff's `--anchored` flag. Other diff tools like
Meld/Araxis Merge also have similar features (called "synchronization
points" or "synchronization links"). We are not using Git/Xdiff's
`--anchored` implementation here because it has a very limited API
(it requires usage of the Patience algorithm, and can only anchor
unique lines that are the same across both files).
Because the user could anchor anywhere, diff anchors could result in
adjacent diff blocks (one block is directly touching another without a
gap), if there is a change right above the anchor point. We don't want
to merge these diff blocks because we want to line up the change at the
anchor. Adjacent diff blocks were first allowed when linematch was
added, but the existing code had a lot of branched paths where
line-matched diff blocks were handled differently. As a part of this
change, refactor them to have a more unified code path that is
generalized enough to handle adjacent diff blocks correctly and without
needing to carve in exceptions all over the place.
closes: #17615
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
John Marriott [Wed, 16 Jul 2025 18:09:13 +0000 (20:09 +0200)]
patch 9.1.1556: string handling in cmdexpand.c can be improved
Problem: string handling in cmdexpand.c can be improved
Solution: Improve string manipulation in cmdexpand.c (John Marriott).
This PR does the following:
In cmdline_fuzzy_completion_supported():
- replace the series of if tests with a switch
In expand_shellcmd_onedir():
- move the code to concatenate path and pattern to expand_shellcmd().
This allows us to slightly simplify the argument list to pass the fully
pathed pattern and the length of the path in the pattern (0 if no path)
- factor out calls to STRMOVE()
In expand_shellcmd():
- factor out calls to STRMOVE() in the first for loop.
- reorganise the second for loop by:
a) only calling vim_strchr() if s is not at the end of the string
b) making sure that when the path and pattern are concatenated they fit
inside buf
c) concatenating path and pattern and pass to expand_shellcmd_onedir()
In globpath():
- slightly improve logic that determines if the complete path will fit
inside the buffer
In f_getcompletion():
- replace the series of if tests with a switch
- factor out calls to STRLEN()
In copy_substring_from_pos():
- factor out the call to STRLEN()
closes: #17742
Signed-off-by: John Marriott <basilisk@internode.on.net> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1555: completion: repeated insertion of leader
Problem: completion: repeated insertion and deletion of complete
functions
Solution: Remove unnecessary insertion and deletion of leader text
('compl_orig_text') during expansion of function present in
'complete' option (Girish Palya).
closes: #17738
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1554: crash when omni-completion opens command-line window
Problem: Vim crashes during omnifunc completion inside the command-line
window ("q:") if the completion item attempts to open an "info"
preview window. This leads to a failed assert during execution.
Solution: Avoid opening preview windows while inside the command-line
window to prevent the crash (Girish Palya).
patch 9.1.1553: Vim9: crash when accessing a variable in if condition
Problem: Vim9: crash when accessing a variable in if condition
(lxhillwind)
Solution: Skip indexing a list/tuple/dict/blob when short-circuiting an
if condition check (Yegappan Lakshmanan)
fixes: #17756
closes: #17768
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1552: [security]: path traversal issue in tar.vim
Problem: [security]: path traversal issue in tar.vim
(@ax)
Solution: warn the user for such things, drop leading /, don't
forcefully overwrite files when writing temporary files,
refactor autoload/tar.vim
tar.vim: drop leading / in path names
A tar archive containing files with leading `/` may cause confusions as
to where the content is extracted. Let's make sure we drop the leading
`/` and use a relative path instead.
Also while at it, had to refactor it quite a bit and increase the
minimum supported Vim version to v9. Also add a test for some basic tar
functionality
patch 9.1.1551: [security]: path traversal issue in zip.vim
Problem: [security]: path traversal issue in zip.vim (@ax)
Solution: drop leading ../ on write of zipfiles, don't forcefully
overwrite existing files
A zip plugin which contains filenames with leading '../' may cause
confusion as to where the content will be extracted. Let's drop such
things and make sure we use a relative filename instead and don't
forcefully overwrite temporary files. Also, warn the user of such
things.
patch 9.1.1550: defaults: 'showcmd' is not enabled in non-compatible mode on Unix
Problem: defaults: 'showcmd' is not enabled in non-compatible mode on
Unix
Solution: Always enable 'showcmd' in non-compatible mode, drop it from
defaults.vim.
'showcmd' was already always enabled in Vim compatible mode except for
UNIX environments. So let's just enable it always, there is no good
reason why UNIX platforms should be handled differently than other
platforms, especially since `defaults.vim` did enable this option
anyhow.
projects / thirdparty / vim.git / log
