feat(completion): fuzzy on default completion

[glepnir]

make fuzzy works on keyword completion.

[glepnir]

need a rebase after revert pr merge.

[chrisbra]

thanks. Can someone test this please?

[techntools]

@chrisbra @glepnir

Thanks for working on this.

Its working but in the screencast below, is it updating the match message correctly ?

fuzzy-keyword.mp4

[glepnir]

try remove fuzzy in completeopt there will still get a wrong status msg. xyz xyb xbc then x -> xy msg still is match x of 3 . because cp_matches not update. I am not sure this is a bug ? if have an issue about this I can try to fix it

[techntools]

@chrisbra What do you think ?

[chrisbra]

@chrisbra What do you think ?

I find it hard to follow. What keys did you press? And does it also happen without fuzzy as @glepnir mentions?

[techntools]

@chrisbra @glepnir

It does also happen without fuzzy as @glepnir mentions

I started with vim -u NONE. Used C-N.

To clear further, as seen in my ss:

1. I type x, press C-N, browse through candidates with C-N, message is match 1 of 4
2. I type z after x while the completion menu still visible, completion menu shows total candidates are only 2, browse through candidates with C-N, message is match 1 of 4. But I think message should be match 1 of 2

But if I press ESC, press C-N, completion menu opens and shows the right value for total matches

[glepnir]

because cp_matches is the count of all candidate words. statusmsg uses it. But when the leader adds or deletes the pum array regenerates , cp_matches is not updated. So it is still the initial count. It should be easy to fix. I just don't know why no one has raised an issue. The default completion has existed for a long time. Someone should have noticed it.

I think it's better to file an issue. this has nothing to do with fuzzy. If others think it's a bug, I can fix it immediately.

[habamax]

Tried it, looks good to me.

[habamax]

However the help topic now incorrect:

	   fuzzy    Enable |fuzzy-matching| for completion candidates. This
		    allows for more flexible and intuitive matching, where
		    characters can be skipped and matches can be found even
		    if the exact sequence is not typed.  Only makes a
		    difference how completion candidates are reduced from the
		    list of alternatives, but not how the candidates are
		    collected (using different completion types).

This part

                                                         Only makes a
		    difference how completion candidates are reduced from the
		    list of alternatives, but not how the candidates are
		    collected (using different completion types).

Currently it also affects how candidates are collected. At least for keywords. Let me check other methods.

[habamax]

okay, there is a regression, at least for line completion, doesn't work at all when fuzzy is in completeopt.

@glepnir pls check following:

1. vim -Nu NONE
2. add 2 lines of text:

world is on fire
no one can save me but you

3. set completeopt+=fuzzy
4. in the new line type w<ctrl-x><ctrl-l>

"world is on fire" should be completed. But it is not:

[Shane-XB-Qian]

because `cp_matches` is the count of all candidate words. `statusmsg` uses it. But when the leader adds or deletes the pum array regenerates , `cp_matches` is not updated. So it is still the initial count. It should be easy to fix. I just don't know why no one has raised an issue. The default completion has existed for a long time. Someone should have noticed it.

this maybe not a bug, here the second c-n after the first one was not same meaning, it still was the first compl. // regardingless what is fuzzy or fuzzycollect going, wish not impact the original compl, // though do welcome you to fix its original real bug if there, thx~

…

-- shane.xb.qian