spell completion is wrong with fuzzy

[habamax]

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?

1. vim --clean
2. :set completeopt+=fuzzy
3. :set spell (probably default vim spell dictionaries needs to be installed?)
4. Paste following text: The rigth thing
5. 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:

Without fuzzy it is.

Version of Vim

9.1.1924

Environment

debian13, bash

Logs and stack traces

[habamax]

Probably fuzzy shouldn't have effect for the spell completion at all.

[dkearns]

I can reproduce it.

[briancarbone]

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 Christian
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'

The majority of his contributions since 9.1.0190 where he first contributed seem to be fixing his own code, and that code attempts to implement his vimscript plugins (e.g. vim-complete) in the C codebase. 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. There's just no way an LLM is capable of understanding the codebase and writing the C code necessary to implement these features correctly.

CC: @chrisbra

As I wrote this, another issue relating to his commits was submitted. It would be prudent to revert all of his commits and lose the broken features now—prior to 9.2—rather than to regret doing so later as the debt accrues.

[chrisbra]

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.

[briancarbone]

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." The complexity of the codebase with its many options and unexpected behaviors are precisely why thorough testing is necessary. This is a reckless cycle of breaking and fixing, and I'm primarily concerned that no one can attest to the quality of the changes made.

Here's more:

9.1.1825 (c51d1cc): Second attempt at LSP flicker fix (after 9.1.1812 was reverted)
9.1.1814 (4403c67): 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. 5+ crashes and an emergency revert in addition to all the bugs is significant compared to the total number of contributions. I noticed @glepnir is not too fond of his recent contribution. Perhaps other maintainers could chime in.

Vim's >30 year legacy of stability shouldn't be sacrificed for these features.

[habamax]

@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.

[zeertzjq]

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.

[girishji]

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.

[girishji]

There are two causes for this issue:

1. Vim’s spell checker uses a trie-based search, which can yield multi-word fragments such as rig the (see the 18th element returned by expand_spelling() in spell.c).
2. 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 (at the minimum). It is also good to have spell expansion not return multi-word items.

(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"
...