[vim/vim] spell completion is wrong with fuzzy (Issue #18800)
Maxim Kim
habamax created an issue (vim/vim#18800)Steps to reproduce
I am not sure if this is my thing only or it could be reproduced by others, @girishji, could you try to repro this?
vim --clean:set completeopt+=fuzzy:set spell(probably default vim spell dictionaries needs to be installed?)- Paste following text:
The rigth thing - Now press
A<CTRL-X><CTRL-S>
Expected behaviour
Popup menu should appear with right being the first element selected.
However, it is not the first element:
image.png (view on web)Without fuzzy it is.
Version of Vim
9.1.1924
Environment
debian13, bash
Logs and stack traces
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18800)Probably fuzzy shouldn't have effect for the spell completion at all.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
dkearns left a comment (vim/vim#18800)I can reproduce it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Brian Carbone
briancarbone left a comment (vim/vim#18800)I was going to hold my tongue since contributing to Vim's codebase is thankless work, but at this point I think it's worth acknowledging. Girish's commits are likely all LLM-generated (which he admits to in his GitHub profile)... but there are constant whac-a-mole "fixes" with his implemented features.
9.1.1812 (71b97f2): Caused crashes, completely reverted by maintainer Christian Brabandt
9.1.1797 (c053350): Broke Ctrl-Y behavior, fixed by his own patch 9.1.1827
9.1.1714 (2eccb4d): Introduced wildmenu regression, fixed by patch 9.1.1737
9.1.1799 (3aa2edb): Crash with autocompletion
9.1.1918 (6437997): Crash with fuzzy completion
9.1.1747 (306a138): Broke redo (.) functionality with preinsert and autocompletion
9.1.1424 (6c40df0): Broke PMenu selection with multi-line selection and limits
9.1.1554 (e4fdb1e): Crash when omni-completion opens command-line window
9.1.1475 (cd68f21): Regression when "nearest" in 'completeopt'
In my naive opinion, Vim doesn't need another bandaid fix layered on... it likely needs an audit of the commits in git log --author="Girish Palya" and a series of reversions.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18800)The Vim code is complex and there are way too many options that influence the bahviour in unexpected ways. I don't think it is fair to accuse @girishji of ai-generating contributions. Instead I think we have improved the completion feature quite a bit, especially with the new autocompletion code. But we will have to fix bugs as we notice them and @girishji has been quite reactive and quickly fixed those issues.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Brian Carbone
briancarbone left a comment (vim/vim#18800)I'd consider it to be more an observation (and the reality) rather than an accusation. He contributed 19 commits over 14 months then 71 commits over 6 months and proclaims "... currently exploring AI/LLMs." It's a reckless cycle of breaking and fixing, and I'm primarily concerned that no one can attest to the quality of the changes made. If another maintainer could defend the history of commits, that would be reassuring.
In the meantime, here's more:
9.1.1825 (c51d1cc): Second attempt at LSP flicker fix (after 9.1.1812 was reverted)
9.1.1814 (4403c67): Christian's revert of 9.1.1812 due to crashes
9.1.1657 (196c376): Fixed delay bug introduced by his own patch 9.1.1638
9.1.1670 (b4e0bd9): Fixed "autocomplete breaks second completion" bug
9.1.1676 (5737930): Fixed "long line shown twice" bug (habamax reported)
9.1.1639 (1e38198): Fixed popup misplacement with 'noselect' in 'wildmode'
The pattern is highly concerning.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#18800)@briancarbone could you please use other means of communications if you have concerns about the contributions of @girishji. Create a new discussion/issue/email in maillist. Let's not hijack this issue. Thank you.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#18800)It's not uncommon for new features to contain various bugs when they interact with old features. The virtual text feature, originally authored by Bram, has undergone many bug fixes in Vim 9.0.xxxx.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18800)Sorry I was out of the country for a while (with family) and decided not to use the computer. I am back, and I will look into these issues.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18800)There are two causes for this issue:
- Vim’s spell checker uses a trie-based search, which can yield multi-word fragments such as
rig the(see the 18th element returned byexpand_spelling()in spell.c). - Fuzzy sorting is then applied to the entire result list, which reorders those entries and surfaces the undesirable multi-word suggestions you’re seeing.
To fix this, do not fuzzy sort items returned directly from spell expansion.
(lldb) p *(char * (*)[100])matches
(char *[100]) {
[0] = 0x00006000027b4de0 "right"
[1] = 0x00006000027b4bc0 "girth"
[2] = 0x00006000027b4ba0 "rig"
[3] = 0x00006000027b4b60 "Right"
[4] = 0x00006000027b4880 "rig Th"
[5] = 0x00006000027b46f0 "with"
[6] = 0x00006000027b7d50 "rig's"
[7] = 0x00006000027b45f0 "rigid"
[8] = 0x00006000027b4ed0 "rigs"
[9] = 0x00006000027b5000 "kith"
[10] = 0x00006000027b4b40 "rigor"
[11] = 0x00006000027b7600 "eight"
[12] = 0x00006000027b75a0 "light"
[13] = 0x00006000027b4be0 "might"
[14] = 0x00006000027b4ab0 "night"
[15] = 0x00006000027b4c40 "rights"
[16] = 0x00006000027b4cf0 "righto"
[17] = 0x00006000027b4d30 "wright"
[18] = 0x00006000027b4770 "rig the"
[19] = 0x00006000027b4540 "Kieth"
[20] = 0x00006000027b45c0 "arith"
...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #18800 as completed via 0e1ab0a.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.