Problem: Another outdated comment in eval.c (after 9.1.1665).
Solution: Remove that comment as well. Add a few more tests for mapnew()
that fail without patch 8.2.1672 (zeertzjq).
closes: vim/vim#180896b56711804
Problem:
with `foldmethod=expr foldexpr=v:lua.vim.treesitter.foldexpr()
foldminlines=0`, deleting lines at the end of the buffer always
reports an invalid top error, because the top value (i.e. the
start line number of the deletion) is always 1 greater than
the total line number of the modified buffer.
Solution:
remove the ml_line_count validation
Problem:
The load function in opts was difficult to use if you wished to
customize based on the plugin being loaded.
You could get the name, but without some way to mark a spec, that was of
limited usefulness unless you wanted to hardcode a list of names in the
function, or write a wrapper around the whole thing
Solution:
Allow users to provide an arbitrary data field in plugin specs so that
they may receive info as to how to handle that plugin in load, get() and
events, and act upon it
Co-authored-by: BirdeeHub <birdee@localhost>
Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Problem: Unable to see e.g. `inputlist()` prompts that exceed the dialog
window height.
Multi-line prompts are not handled properly, and tracking
is insufficient for messages in cmdline_block mode.
Solution: Add vim.on_key handler while the dialog window is open that
forwards paging keys to the window.
Properly render multi-line prompts. Keep track of both the start
and end of the current cmdline prompt. Append messages after the
current prompt in cmdline_block mode.
Problem:
Running `echo dummy | nvim file1 file2` closes the file1 buffer if
file1 doesn't exist.
Solution:
Logic changed in 43e8ec9 such that stdin buffer may now be created *after*
file args. Handle that case.
Problem: Wrong event order for nested cmdline in a conditional cmdline_block.
Solution: Emit all but the first cmdline_block event immediately after
getting the next command, before executing it.
Problem: filetype: Cangjie files are not recognized
Solution: Detect *.cj files as cangjie filetype, include a syntax plugin
(WuJunkai2004)
This commit introduces a new syntax highlighting file for the Cangjie
programming language, includes 4 parts as required:
- The main syntax file: runtime/syntax/cangjie.vim
- The filetype detection rule in: runtime/filetype.vim
- The documentation update in: runtime/doc/syntax.txt
- Some menus
References:
- https://gitcode.com/Cangjie
- https://cangjie-lang.cn/
fixes: 18014
closes: vim/vim#180270c4405a6b2
Co-authored-by: WuJunkai2004 <wujunkai20041123@outlook.com>
Problem: many FileType autocommands assume curbuf is the same as the target
buffer; this can cause &syntax to be restored for the wrong buffer in some cases
when TSHighlighter:destroy is called.
Solution: run nvim_exec_autocmds in the context of the target buffer via
nvim_buf_call.
Problem: on_detach may be called after buf_freeall and other important things,
plus its textlock restrictions are insufficient. This can cause issues such as
leaks, internal errors and crashes.
Solution: disable buffer updates in buf_freeall, before autocommands (like the
order after #35355 and when do_ecmd reloads a buffer). Don't do so in
free_buffer_stuff; it's not safe to run user code there, and buf_freeall already
runs before then; just free them to avoid leaks if buf_freeall autocommands
registered more for some reason.
Fixes#28084Fixes#33967Fixes#35116
Problem:
Buffer-updates on_detach callback is invoked before buf_freeall(), which
deletes autocmds of the buffer (via apply_autocmds(EVENT_BUFWIPEOUT,
...)). Due to this, buffer-local autocmds executed in on_detach (e.g.,
LspDetach) are not actually invoked.
Solution:
Call buf_updates_unload() before buf_freeall().
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: vim/vim#17990c08b94b072
Co-authored-by: David Friant <friant@HPEnvyx360.friant.dev>
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: vim/vim#17403closes: vim/vim#179288f9de4991e
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
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: vim/vim#17992891353671a
These are not needed after #35129 but making uncrustify still play nice
with them was a bit tricky.
Unfortunately `uncrustify --update-config-with-doc` breaks strings
with backslashes. This issue has been reported upstream,
and in the meanwhile auto-update on every single run has been disabled.
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.
related: neovim/neovim#34101fixesvim/vim#17531closes: vim/vim#179007e0df5eee9
Co-authored-by: Girish Palya <girishji@gmail.com>
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: vim/vim#2090fixes: vim/vim#12491closes: vim/vim#178655ba6e41d37
Co-authored-by: Anttoni Erkkilä <anttoni.erkkila@protonmail.com>
Problem: parse_cmdline() sets eap->cmdlinep to address of local parameter,
causing invalid memory access when expand_filename() tries to modify it.
This leads to crashes when typing '%' in user commands with preview=true
and complete=file.
Solution: Change parse_cmdline() signature to accept char **cmdline,
allowing cmdlinep to point to caller's variable for safe reallocation.
Problem:
During preview, the `input` still prompts the user to enter something
that won't be used later, which could be a bit confusing.
e.g., `:s/a/\=input("")`.
Solution:
Make the input() return early during 'inccommand' preview.
Problem: Temporary cmdline config is saved to be restored later.
Solution: Close the cmdline window so that it is recreated with the appropriate config.
Problem: Patch v9.1.1432 causes performance regressions
Solution: Revert "patch 9.1.1432: GTK GUI: Buffer menu does not handle
unicode correctly" (Yee Cheng Chin).
This reverts commit 08896dd330c6dc8324618fde482db968e6f71088.
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: vim/vim#17405
related: vim/vim#17928fixes: vim/vim#17897cda0d17f59
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: Incorrect E535 error message (after 9.1.1603).
Solution: Don't use transchar(), as the character is always printable
(zeertzjq).
closes: vim/vim#17948b362995430
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: vim/vim#179528e2a229189
Co-authored-by: Robert Muir <rmuir@apache.org>
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Problem: tests: test_search leaves a few swapfiles behind
Solution: Use :bw! instead of :close to close the swapfile at the end of
the test.
related: vim/vim#17933a2bb21a895
Co-authored-by: Christian Brabandt <cb@256bit.org>
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.
fixes: vim/vim#17895closes: vim/vim#17933c03990d30f
Co-authored-by: Christian Brabandt <cb@256bit.org>
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
fixes: vim/vim#17946887b4981e7
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: No way to skip install confirmation in `add()`. Having install
confirmation by default is a more secure design. However, users are
usually aware of the fact that plugin will be installed and there is
currently no way to skip confirmation.
Plus it can introduce inconvenience on the clean config initialization
if it is modularized with many `vim.pack.add()` calls (leads to
confirming installation many times in a row).
Solution: Add `opts.confirm` option that can skip install confirmation.
Problem: No way to have full control over how plugin is loaded.
Although `:packadd!` has small side effects (only adds plugin
directory to 'runtimepath'; and maybe its 'after/' subdirectory), it
still has side effects. For example, 'plugin/' directories are still
loaded during startup (as part of `:h load-plugins`).
Solution: Allow function `opts.load` that has full control over how
plugin is loaded.
