patch 9.1.1768: Makefile does not uninstall global plugins
Problem: Makefile does not uninstall global plugins
(after v9.1.1757)
Solution: Uninstall global plugins before installing them,
so that old files are not carried around and loaded
when no longer used.
Problem: Patch v9.1.1765 was wrong
Solution: Roll back the change, it's correct to have call_func()
initialize the type, so that not each function has to
do this on its own.
patch 9.1.1766: Vim9: some functions do not handle null_string correctly
Problem: Vim9: some Vim9 functions do not handle null_string correctly
and may crash Vim (kennypete).
Solution: Check for null_string correctly in the searchpair() and
substitute() functions (Yegappan Lakshmanan).
fixes: #18309
closes: #18311
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Maxim Kim [Mon, 15 Sep 2025 19:47:20 +0000 (19:47 +0000)]
runtime(colors): update colorschemes:
- Add PreInsert (darkblue, habamax, lunaperche, wildcharm, retrobox).
- Update QuickFixLine (habamax, lunaperche, wildcharm, retrobox) - make
it foreground transparent in GUI.
- Make Todo in wildcharm just bold.
closes: #18304
Signed-off-by: Maxim Kim <habamax@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Jon Parise [Mon, 15 Sep 2025 19:35:47 +0000 (19:35 +0000)]
patch 9.1.1764: filetype: CODEOWNERS file not recognized
Problem: filetype: CODEOWNERS file not recognized
Solution: Detect CODEOWNERS file as codeowners filetype, include a
syntax and filetype plugin (Jon Parise).
CODEOWNERS files define code ownership rules for GitHub-hosted (and
other) repositories. The syntax is similar to 'gitignore' files but
differs in enough ways to warrant its own filetype.
Problem: 'ruler' is set in defaults.vim, but not enabled by default in
non-compatible mode.
Solution: set the ruler option in non-compatible mode, remove it from
defaults.vim, update tests
patch 9.1.1758: Diff mode crashes when adding text property in autocommand
Problem: Diff mode crashes when adding text property in autocommand
(after 9.1.1557).
Solution: Only restore ML_EMPTY memline flag, ignore the others
(zeertzjq).
fixes: #18288
closes: #18291
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
D. Ben Knoble [Sun, 14 Sep 2025 08:42:25 +0000 (04:42 -0400)]
runtime(html): guard against an existing b:undo_ftplugin var
Filetype plugins should not assume they are the only file to execute on
behalf of a buffer's filetype: other filetypes may use them, and
dotted filetypes may cause multiple to run. When this occurs, they
should _build_ on their respective b:undo_ftplugin settings, not
overwrite each other.
For example, when using a dotted filetype wiki.markdown, the wiki
filetype plugins go first. Then, during the markdown filetype plugins,
the HTML plugin's unconditional assignment to b:undo_ftplugin trashes
any data previously stored there by the wiki filetype.
Follow the pattern elsewhere of assigning or appending conditionally.
closes: #18267
Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com> Signed-off-by: Doug Kearns <dougkearns@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1757: The colorresp plugin causes additional redraws
Problem: The colorresp plugin causes additional redraws
(Linwei, after v9.1.1703)
Solution: Move the code back into the C core and get rid of the vim
plugin (Foxe Chen)
fixes: #18251
closes: #18279
Signed-off-by: Foxe Chen <chen.foxe@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1753: defaults: 'diffopt' option value can be improved
Problem: defaults: 'diffopt' option value can be improved
Solution: Update diffopt defaults to include "indent-heuristic" and
"inline:char" (Yee Cheng Chin)
The default diff options have not been updated much despite new
functionality having been added to Vim.
- indent-heurstic: This has been enabled by default in Git since 33de716387 in 2017. Given that Vim uses xdiff from Git, it makes sense
to track the default configuration from Git.
- inline:char: This turns on character-wise inline highlighting which is
generally much better than the default inline:simple. It has been
implemented since #16881 and we have not seen reports of any issues
with it, and it has received good feedbacks.
closes: #18255
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1752: tests: need another test for v9.1.1750 behaviour
Problem: tests: No test when deleting text after autocompletion with preinsert
did complete an entry
Solution: Verify, that after deletion autocompletion does not reinsert
the deleted text. Note: the actual issue was fixed with v9.1.1750.
(Girish Palya)
Pre v9.1.1750 behaviour:
When autocomplete is enabled with *preinsert*, deleting text after selecting a
longer match could cause unintended reinsertion, e.g.:
- Matches available: "foo" and "foobar".
- User selects "foobar" with Ctrl-N
- User deletes characters back to "foo".
- Autocomplete then incorrectly re-inserts "bar", preventing deletion past "foo".
v9.1.1750 removes the unwanted reinsertion so text can be deleted correctly.
closes: #18259
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1750: completion: preinserted text highlighed using ComplMatchIns
Problem: completion: preinserted text highlighed using ComplMatchIns
Solution: Use highlighting group PreInsert and update the documentation
(Girish Palya).
When "preinsert" is included in 'completeopt', only the PreInsert
highlight group should be applied, whether autocompletion is active or not.
Previously, ComplMatchIns was used when autocompletion was not enabled.
Related to https://github.com/vim/vim/pull/18213.
closes: #18254
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
This is a trickier pattern to match because we can't rely on keyword
boundaries, so we instead look for exactly three dots (`...`).
This does mean that we will match the `...` portion of `x...x`, which
isn't valid Python syntax, but I think that's an acceptable trade-off
that avoids making this pattern much more complex.
Problem: Haiku: no full-screen support
Solution: Add support for toggling full-screen using the keyboard
(rymdbar)
Makes toggling using keyboard possible. This change does not add any
`:fullscreen` command (Which currently only macVim has).
See https://www.haiku-os.org/docs/userguide/en/keyboard-shortcuts.html
for motivation on key combination used, as well as terminology choice.
With vim being inconsistent (`:help intro` suggests <A> and <M>, while
<Alt> is used at a dozen other places) following Haiku nomenclature
seems most appropriate.
closes: #18235
Signed-off-by: rymdbar <rymdbar@x20.se> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1740: Memory leak with wildmode=longest,full and wildoptions=pum
Problem: Memory leak with wildmode=longest,full and wildoptions=pum
(after 9.1.1737).
Solution: Avoid using showmatches() and WILD_NEXT together. Also fix
wildmode=longest,noselect:full selecting wrong item
(zeertzjq).
fixes: #18228
closes: #18229
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1739: Matches may be listed twice with wildmode=longest,list
Problem: Matches may be listed twice with wildmode=longest,list when
"longest" doesn't change command line (after 9.1.1737).
Solution: Set did_wild_list when trying "list" after "longest"
(zeertzjq).
closes: #18227
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1737: Patch v9.1.1714 introduce a regression for wildmenu
Problem: Patch v9.1.1714 introduce a regression for wildmenu (zeertzjq)
Solution: Restore behavior of "longest" in 'wildmode' (Girish Palya)
- Fixed a regression caused by PR #18125 selecting wrong item
- Fixed another regression where the first pasted text did not appear on
the command-line after starting Vim.
closes: #18212
Signed-off-by: Girish Palya <girishji@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1735: Cygwin Makefile still checks for Win XP version
Problem: Cygwin Makefile still checks for Win XP version
Solution: Remove check for WINVER >= 0x600 in Make_cyg_ming.mak
(Mao-Yining)
Vim's does no longer support Windows XP and Vista since v9.0.0496. So
the condition in Make_cyg_ming.mak to check for any Windows version below
Vista can be removed.
fixes: #18160
closes: #18215
Signed-off-by: Mao-Yining <mao.yining@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.1734: Memory leak when allocating match fails
Problem: Memory leak when allocating match fails
Solution: Initialize m to NULL and centralize cleanup via goto fail to
avoid leaks on early returns (Damien Lejay)
Martin Schwan [Thu, 4 Sep 2025 20:09:26 +0000 (22:09 +0200)]
patch 9.1.1732: filetype: .inc file detection can be improved
Problem: filetype: .inc file detection can be improved
Solution: Update filetype detection for Pascal and BitBake code
(Martin Schwan).
Fix the detection of .inc files containing Pascal and BitBake code:
- the concatenated string, merged from three lines, only contains one
beginning and the pattern "^" would not match as expected. Use a range()
loop to iterate each line string individually. This way, the pattern "^"
works for beginning of lines.
- improve BitBake include file detection by also matching forward-slashes
"/" in variable names and assignment operators with a dot ".=" and "=.".
Valid examples, which should match, are:
This change does the following to the M4 syntax script:
- In M4 there are no "strings" in the usual sense. Instead, M4 has
quotes, but the text inside a quoted region is rescanned just like
outside, and quotes can be nested.
- The old m4String region was misleading and removed. A new m4Quoted
region reflects proper quoting semantics.
- Removed a duplicate highlight rule.
- Fixed a typo in a highlight group name (m4builtin → m4Builtin).
- Added a reference link to the POSIX M4 specification.
- Removed outdated maintainer URL.
closes: #18192
Signed-off-by: Damien Lejay <damien@lejay.be> Signed-off-by: Christian Brabandt <cb@256bit.org>