glepnir [Sun, 17 Aug 2025 19:40:45 +0000 (21:40 +0200)]
patch 9.1.1645: fuzzy.c can be further improved
Problem: fuzzy.c can be further improved
Solution: Fix memory leak and refactor it (glepnir).
Optimize performance and memory allocation:
- Fix memory leak in fuzzy_match_in_list.
- using single memory allocation in match_positions
- Improve has_match performance and add null pointer checks
closes: #18012
Signed-off-by: glepnir <glephunter@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Damien Lejay [Sun, 17 Aug 2025 19:25:07 +0000 (21:25 +0200)]
patch 9.1.1644: configure: doesn't separate CPPFLAGS and CFLAGS
Problem: configure: doesn't separate CPPFLAGS and CFLAGS
Solution: Split CPPFLAGS and CFLAGS for pkg-config
(Damien Lejay)
Previously, all flags returned by pkg-config --cflags were dumped into
CFLAGS, mixing include paths with compiler options. This commit uses
--cflags-only-I and --cflags-only-other to properly separate include
flags into CPPFLAGS and keep compiler flags in CFLAGS.
closes: #18019
Signed-off-by: Damien Lejay <damien@lejay.be> Signed-off-by: Christian Brabandt <cb@256bit.org>
David Friant [Sat, 16 Aug 2025 16:30:55 +0000 (18:30 +0200)]
patch 9.1.1640: Unicode has deprecated some code-points
Problem: Unicode has deprecated some code-points
Solution: Update the digraph tables to align with the Unicode v16
release (David Friant)
This commit updates the digraphs Left-Pointing Angle Bracket '</'
and Right-Pointing Angle Bracket '/>' to account for the fact that
the old Unicode codepoints for them (2329 and 232A, respectively)
have been deprecated. As per the Miscellaneous Technical code chart
(https://www.unicode.org/charts/PDF/U2300.pdf), the old digraphs
have been reassigned to the CJK Left Angle Bracket and Right Angle
Bracket (3008 and 3009) with their declaration moved to the
appropriate block.
This commit also introduces the new digraphs '<[' and ']>' to
represent the Mathematical Left Angle Bracket and Mathematical
Right Angle Bracket (27E8 and 27E9) to replace the deprecated code
points in the Technical block.
Tests have been added and, I believe, the documentation has been
updated accordingly.
closes: #17990
Signed-off-by: David Friant <friant@HPEnvyx360.friant.dev> Signed-off-by: Christian Brabandt <cb@256bit.org>
Girish Palya [Sat, 16 Aug 2025 16:13:46 +0000 (18:13 +0200)]
patch 9.1.1639: completion: popup may be misplaced
Problem: During commandline completiom, popup window placement can be
incorrect when 'noselect' is present in 'wildmode'
(Shane-XB-Qian)
Solution: Disable "showtail" feature when 'noselect' is present.
fixes: #17969
closes: #18001
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Girish Palya [Sat, 16 Aug 2025 16:04:04 +0000 (18:04 +0200)]
patch 9.1.1638: completion: not possible to delay the autcompletion
Problem: completion: not possible to delay the autcompletion
Solution: add the 'autocompletedelay' option value (Girish Palya).
This patch introduces a new global option 'autocompletedelay'/'acl' that
specifies the delay, in milliseconds, before the autocomplete menu
appears after typing.
When set to a non-zero value, Vim waits for the specified time before
showing the completion popup, allowing users to reduce distraction from
rapid suggestion pop-ups or to fine-tune the responsiveness of
completion.
The default value is 0, which preserves the current immediate-popup
behavior.
closes: #17960
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Foxe Chen [Thu, 14 Aug 2025 20:08:17 +0000 (22:08 +0200)]
patch 9.1.1634: Clipboard code can be improved
Problem: Clipboard code can be improved
Solution: Slightly refactor code (Foxe Chen).
This commit does the following:
- Use garray_T when receiving data instead of manually reallocing
- formatting fixes
- skip Wayland test that requires clientserver if x11 not compiled
- Make some functions static
closes: #17999
Signed-off-by: Foxe Chen <chen.foxe@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
zeertzjq [Thu, 14 Aug 2025 18:34:08 +0000 (20:34 +0200)]
patch 9.1.1630: tests: fuzzy bufname completion test doesn't match successfully
Problem: tests: fuzzy buffer name completion test doesn't match
successfully (after 9.1.1627).
Solution: Update pattern to account for the change in case sensitivity.
Also mark Test_search_stat_option() as flaky as it can still
sometimes fail (zeertzjq).
closes: #17992
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1629: Vim9: Not able to use more than 10 type arguments in a generic function
Problem: Vim9: Not able to use more than 10 type arguments in a generic
function
Solution: Initialize the types after reading all the type arg variable
names (Yegappan Lakshmanan)
closes: #17981
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Jon Parise [Wed, 13 Aug 2025 20:34:51 +0000 (22:34 +0200)]
runtime(python): highlight "self" and "cls" in syntax script
These are special names by convention, and giving them distinct
highlighting is a nice visual clue (using Identifier by default).
This group is named "pythonClassVar" to match the name used by
python-syntax. Some third-party color schemes are aware of this
name and customized their colors accordingly.
closes: #17968
Signed-off-by: Jon Parise <jon@indelible.org> Signed-off-by: Zvezdan Petkovic <zpetkovic@acm.org> Signed-off-by: Christian Brabandt <cb@256bit.org>
glepnir [Wed, 13 Aug 2025 20:02:30 +0000 (22:02 +0200)]
patch 9.1.1628: fuzzy.c has a few issues
Problem: fuzzy.c has a few issues
Solution: Use Vims memory management, update style
(glepnir)
Problem:
- Missing cleanup of lmatchpos lists causing memory leaks
- Missing error handling for list operations
- Use of malloc() instead of Vim's alloc() functions
- Inconsistent C-style comments
- Missing null pointer checks for memory allocation
- Incorrect use of vim_free() for list objects
Solution:
- Add proper cleanup of lmatchpos in done section using list_free()
- Set lmatchpos to NULL after successful transfer to avoid confusion
- Add error handling for list_append_tv() failures
- Replace malloc() with alloc() and add null pointer checks
- Convert C-style comments to C++ style for consistency
- Fix vim_free() calls to use list_free() for list objects
closes: #17984
Signed-off-by: glepnir <glephunter@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Girish Palya [Tue, 12 Aug 2025 20:22:52 +0000 (22:22 +0200)]
patch 9.1.1627: fuzzy matching can be improved
Problem: fuzzy-matching can be improved
Solution: Implement a better fuzzy matching algorithm
(Girish Palya)
Replace fuzzy matching algorithm with improved fzy-based implementation
The
[current](https://www.forrestthewoods.com/blog/reverse_engineering_sublime_texts_fuzzy_match/)
fuzzy matching algorithm has several accuracy issues:
* It struggles with CamelCase
* It fails to prioritize matches at the beginning of strings, often
ranking middle matches higher.
After evaluating alternatives (see my comments
[here](https://github.com/vim/vim/issues/17531#issuecomment-3112046897)
and
[here](https://github.com/vim/vim/issues/17531#issuecomment-3121593900)),
I chose to adopt the [fzy](https://github.com/jhawthorn/fzy) algorithm,
which:
* Resolves the aforementioned issues.
* Performs better.
Implementation details
This version is based on the original fzy
[algorithm](https://github.com/jhawthorn/fzy/blob/master/src/match.c),
with one key enhancement: **multibyte character support**.
* The original implementation supports only ASCII.
* This patch replaces ascii lookup tables with function calls, making it
compatible with multibyte character sets.
* Core logic (`match_row()` and `match_positions()`) remains faithful to
the original, but now operates on codepoints rather than single-byte
characters.
Performance
Tested against a dataset of **90,000 Linux kernel filenames**. Results
(in milliseconds) show a **\~2x performance improvement** over the
current fuzzy matching algorithm.
```
Search String Current Algo FZY Algo
-------------------------------------------------
init 131.759 66.916
main 83.688 40.861
sig 98.348 39.699
index 109.222 30.738
ab 72.222 44.357
cd 83.036 54.739
a 58.94 62.242
b 43.612 43.442
c 64.39 67.442
k 40.585 36.371
z 34.708 22.781
w 38.033 30.109
cpa 82.596 38.116
arz 84.251 23.964
zzzz 35.823 22.75
dimag 110.686 29.646
xa 43.188 29.199
nha 73.953 31.001
nedax 94.775 29.568
dbue 79.846 25.902
fp 46.826 31.641
tr 90.951 55.883
kw 38.875 23.194
rp 101.575 55.775
kkkkkkkkkkkkkkkkkkkkkkkkkkkkk 48.519 30.921
```
```vim
vim9script
var haystack = readfile('/Users/gp/linux.files')
var needles = ['init', 'main', 'sig', 'index', 'ab', 'cd', 'a', 'b',
'c', 'k',
'z', 'w', 'cpa', 'arz', 'zzzz', 'dimag', 'xa', 'nha', 'nedax',
'dbue',
'fp', 'tr', 'kw', 'rp', 'kkkkkkkkkkkkkkkkkkkkkkkkkkkkk']
for needle in needles
var start = reltime()
var tmp = matchfuzzy(haystack, needle)
echom $'{needle}' (start->reltime()->reltimefloat() * 1000)
endfor
```
Additional changes
* Removed the "camelcase" option from both matchfuzzy() and
matchfuzzypos(), as it's now obsolete with the improved algorithm.
Anttoni Erkkilä [Tue, 12 Aug 2025 19:59:06 +0000 (21:59 +0200)]
patch 9.1.1626: cindent: does not handle compound literals
Problem: C-indent does not handle compound literals
(@44100hertz, @Jorenar)
Solution: Detect and handle compound literal and structure
initialization (Anttoni Erkkilä)
match '=' or "return" optionally followed by &, (typecast), {
Fixes also initialization which begins with multiple opening braces.
fixes: #2090
fixes: #12491
closes: #17865
Signed-off-by: Anttoni Erkkilä <anttoni.erkkila@protonmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Girish Palya [Tue, 12 Aug 2025 19:38:56 +0000 (21:38 +0200)]
patch 9.1.1625: Autocompletion slow with include- and tag-completion
Problem: Autocompletion slow with include- and tag-completion
Solution: Refactor ins_compl_interrupted() to also check for timeout,
further refactor code to skip outputting message when
performing autocompletion (Girish Palya).
Running `vim *` in `vim/src` was slower than expected when
'autocomplete' was enabled. Include-file and tag-file completion
sources were not subject to the timeout check, causing unnecessary
delays.
So apply the timeout check to these sources as well, improving
autocompletion responsiveness, refactor find_pattern_in_path() to take
an additional "silent" argument, to suppress any messages.
closes: #17966
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Shane-XB-Qian [Tue, 12 Aug 2025 19:28:28 +0000 (21:28 +0200)]
runetime(vim): gf maybe hang and fail
* searching'**' maybe terrible slow
* searching '**/plugin/' maybe fail
* the pattern for the :packadd/:import/:colorscheme
did not consistently check for a colon, so always use
'\%(:\s*\)\=' before the actual ex command
While at it rename the generic name vim.vim to vimgoto.vim as this more
clearly states what this script is for.
Signed-off-by: Shane-XB-Qian <shane.qian@foxmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Damien Lejay [Tue, 12 Aug 2025 18:46:50 +0000 (20:46 +0200)]
patch 9.1.1624: Cscope not enabled on MacOS
Problem: Cscope not enabled on MacOS
Solution: Remove #ifdef test for MacOS and always enable FEAT_CSCOPE on
Unix (Damien Lejay).
Remove the !MACOS_X guard from FEAT_CSCOPE in feature.h. macOS has been a
certified UNIX since 10.5 and supports cscope without issues. This guard
originated in the pre-OS X era when Classic MacOS lacked the required
POSIX APIs. MacVim already ships with +cscope successfully.
closes: #17976
Signed-off-by: Damien Lejay <damien@lejay.be> Signed-off-by: Christian Brabandt <cb@256bit.org>
Jon Parise [Mon, 11 Aug 2025 18:33:33 +0000 (20:33 +0200)]
runtime(python): Also sync syntax at 'async def'
A file containing only async functions (`async def func()`) wouldn't
previously match the pythonSync pattern.
Also, this pattern only matches at the beginning of the line, so it
won't ever match method definitions (which are indented within class
scopes). Update the comment accordingly.
closes: #17963
Signed-off-by: Jon Parise <jon@indelible.org> Signed-off-by: Zvezdan Petkovic <zpetkovic@acm.org> Signed-off-by: Christian Brabandt <cb@256bit.org>
Jon Parise [Sun, 10 Aug 2025 08:32:41 +0000 (10:32 +0200)]
runtime(python): Highlight classes as structures
Class and function definitions previously shared a single highlight
group (pythonFunction). This change gives classes their own highlight
group (pythonClass) that's linked to Structure.
closes: #17856
Signed-off-by: Jon Parise <jon@indelible.org> Signed-off-by: Zvezdan Petkovic <zpetkovic@acm.org> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1623: Buffer menu does not handle unicode names correctly
Problem: Buffer menu does not handle unicode names correctly
(after v9.1.1622)
Solution: Fix the BMHash() function (Yee Cheng Chin)
The Buffers menu uses a BMHash() function to generate a sortable number
to be used for the menu index. It used a naive (and incorrect) way of
encoding multiple ASCII values into a single integer, but assumes each
character to be only in the ASCII 32-96 range. This means if we use
non-ASCII file names (e.g. Unicode values like CJK or emojis) we get
integer underflow and overflow, causing the menu index to wrap around.
Vim's GUI implementations internally use a signed 32-bit integer for the
`gui_mch_add_menu_item()` function and so we need to make sure the menu
index is in the (0, 2^31-1) range.
To do this, if the file name starts with a non-ASCII value, we just use
the first character's value and set the high bit so it sorts after the
other ASCII ones. Otherwise, we just take the first 5 characters, and
use 5 bit for each character to encode a 30-bit number that can be
sorted.
This means Unicode file names won't be sorted beyond the first
character. This is likely going to be fine as there are lots of ways to
query buffers.
related: #17403
closes: #17928
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
The previous change to support Unicode characters properly in the
buffers menu resorted to removing all buffer menus and re-add the
buffers after doing a sort, per each buffer addition. This was quite
slow because if Vim is trying to load in multiple buffers at once (e.g.
when loading a session) this scales in O(n^2) and Vim can freeze for
dozens of seconds when adding a few hundred buffers.
related: #17405
related: #17928
fixes: #17897
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Girish Palya [Fri, 8 Aug 2025 06:26:03 +0000 (08:26 +0200)]
patch 9.1.1621: flicker in popup menu during cmdline autocompletion
Problem: When the popup menu (PUM) occupies more than half the screen
height, it flickers whenever a character is typed or erased.
This happens because the PUM is cleared and the screen is
redrawn before a new PUM is rendered. The extra redraw between
menu updates causes visible flicker.
Solution: A complete, non-hacky fix would require removing the
CmdlineChanged event from the loop and letting autocompletion
manage the process end-to-end. This is because screen redraws
after any cmdline change are necessary for other features to
work.
This change modifies wildtrigger() so that the next typed
character defers the screen update instead of redrawing
immediately. This removes the intermediate redraw, eliminating
flicker and making cmdline autocompletion feel smooth
(Girish Palya).
Trade-offs:
This behavior change in wildtrigger() is tailored specifically for
:h cmdline-autocompletion. wildtrigger() now has no general-purpose use
outside this scenario.
closes: #17932
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Dietrich Moerman [Sun, 10 Aug 2025 07:44:42 +0000 (09:44 +0200)]
patch 9.1.1620: filetype: composer.lock and symfony.lock files not recognized
Problem: filetype: composer.lock and symfony.lock files not recognized
Solution: Detect composer.lock and symfony.lock files as json filetype
(Dietrich Moerman)
closes: #17945
Signed-off-by: Dietrich Moerman <dietrich.moerman@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
veotos [Sun, 10 Aug 2025 07:27:17 +0000 (09:27 +0200)]
runtime(doc): Fix style and typos in builtin.txt and usr_41.txt
- Reformat parts to fit into 80 column window.
- Fix example with mandatory call with a range.
https://github.com/vim/vim/discussions/17950#discussioncomment-14055687
- Remove some duplicate information
closes: #17949
Signed-off-by: veotos <veotos@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Robert Muir [Sun, 10 Aug 2025 07:19:36 +0000 (09:19 +0200)]
patch 9.1.1618: completion: incorrect selected index returned from complete_info()
Problem: completion: incorrect selected index returned from
complete_info()
Solution: Return the index into "items" and restore the previous
behaviour (Robert Muir).
complete_info() returned an incorrect selected index after 0ac1eb3555445f4c458c06cef7c411de1c8d1020 (Patch v9.1.1311). Effectively
it became an index into "matches" instead of "items". Return the index
into "items" by default to restore the previous behavior, unless
"matches" was requested.
closes: #17952
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com> Signed-off-by: Robert Muir <rmuir@apache.org> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1617: Vim9: some error messages can be improved
Problem: Vim9: some error messages can be improved
Solution: Improve error messages when parsing generic function type
arguments (Yegappan Lakshmanan).
closes: #17957
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
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
projects / thirdparty / vim.git / log
