[vim/vim] complete() with one item and completeopt=fuzzy,longest sometimes doesn't work? (Issue #19008)
D. Ben Knoble
benknoble created an issue (vim/vim#19008)I've narrowed it down as much as I can for the moment, but I'm not yet sure there's a bug. It goes like this:
-
Put the following text in
clean.vim:" load with vim --clean -u <this-file> if &compatible set nocompatible endif set completeopt+=fuzzy,longest inoremap <C-a> <C-r>=complete(col('.') - getline('.')->matchstr('\<\f\+\%'.col('.').'c')->strlen(), ['item'])<enter> -
Run
vim --clean -u clean.vim, theni<C-a>. With this reproduction, I get a "0" inserted in the buffer and no completion.
In my actual use case (see also mapping), I just get nothing inserted and no completion.
My current version is below
VIM - Vi IMproved 9.1 (2024 Jan 02, compilé Dec 20 2025 21:43:43)
Rustines incluses : 1-2001
Modifié par Gentoo-9999 (RIP Bram)
Compilé par benknoble@localhost
Énorme version sans interface graphique. Fonctionnalités incluses (+) ou non (-) :
+acl
+arabic
+autocmd
+autochdir
-autoservername
-balloon_eval
+balloon_eval_term
-browse
++builtin_terms
+byte_offset
+channel
+cindent
+clientserver
+clipboard
+clipboard_provider
+cmdline_compl
+cmdline_hist
+cmdline_info
+comments
+conceal
+cryptv
-cscope
+cursorbind
+cursorshape
+dialog_con
+diff
+digraphs
-dnd
-ebcdic
+emacs_tags
+eval
+ex_extra
+extra_search
-farsi
+file_in_path
+find_in_path
+float
+folding
-footer
+fork()
+gettext
-hangul_input
+iconv
+insert_expand
+ipv6
+job
+jumplist
+keymap
+lambda
+langmap
+libcall
+linebreak
+lispindent
+listcmds
+localmap
-lua
+menu
+mksession
+modify_fname
+mouse
-mouseshape
+mouse_dec
+mouse_gpm
-mouse_jsbterm
+mouse_netterm
+mouse_sgr
-mouse_sysmouse
+mouse_urxvt
+mouse_xterm
+multi_byte
+multi_lang
-mzscheme
+netbeans_intg
+num64
+packages
+path_extra
-perl
+persistent_undo
+popupwin
+postscript
+printer
+profile
-python
-python3
+quickfix
+reltime
+rightleft
-ruby
+scrollbind
+signs
+smartindent
-socketserver
+sodium
+sound
+spell
+startuptime
+statusline
-sun_workshop
+syntax
+tabpanel
+tag_binary
-tag_old_static
-tag_any_white
-tcl
+termguicolors
+terminal
+terminfo
+termresponse
+textobjects
+textprop
+timers
+title
-toolbar
+user_commands
+vartabs
+vertsplit
+vim9script
+viminfo
+virtualedit
+visual
+visualextra
+vreplace
-wayland
-wayland_clipboard
-wayland_focus_steal
+wildignore
+wildmenu
+windows
+writebackup
+X11
+xattr
+xfontset
-xim
-xpm
+xsmp_interact
+xterm_clipboard
-xterm_save
fichier vimrc système : "/etc/vim/vimrc"
fichier vimrc utilisateur : "$HOME/.vimrc"
2e fichier vimrc utilisateur : "~/.vim/vimrc"
3e fichier vimrc utilisateur : "~/.config/vim/vimrc"
fichier exrc utilisateur : "$HOME/.exrc"
fichier de valeurs par défaut : "$VIMRUNTIME/defaults.vim"
$VIM par défaut : "/usr/share/vim"
Compilation : x86_64-pc-linux-gnu-gcc -c -I. -Iproto -DHAVE_CONFIG_H -march=native -O2 -pipe -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Édition de liens : x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -L/usr/local/lib -o vim -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lcanberra -lsodium -lacl -lattr -lgpm
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#19008)A few other symptoms:
- At work, I don't have the original issue (version 9.1.1883 for macOS arm64), but the reproducer still inserts a 0. However, pressing C-a a second time inserts "item" before the 0.
- On the machine and version showing this problem, completions where you press the combination again immediately after accepting a completion (_e.g., C-x C-l C-x C-l) don't insert anything, but a second press (C-l) does insert the next line as expected.
- Also on that machine, line completion completes the whole line after leading whitespace, temporarily rendering with too much indent. Accepting the completion does fix the indent. This does not happen on the work machine mentioned above either.
This tells me it's either
- a patch in the range of versions
- a Linux vs macOS issue
- a compiler difference (flags, etc.)
🤔
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#19008)On yet a third (macOS x86_64) machine, version 9.1.1775, I also don't see this issue; I also have the C-a -> 0 -> item0 from the reproducer, and repeated completion and line completion behave as expected.
That doesn't really rule out my hypotheses above, but it makes me more convinced that one of the 3 is at stake.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#19008)Ok, a fresh build on this machine (just make, nothing special) in a checkout of 2e4c98b (runtime(vim): Update base syntax, match Vim9 :unlet command, 2026-02-01) exhibits the same problem as the OP says:
With this reproduction, I get a "0" inserted in the buffer and no completion.
Might be a runtime difference? I'm going to try to run Vim under a debugger on multiple systems and see what I get, but I'm not really sure how to narrow down the issue at this point.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
D. Ben Knoble
benknoble left a comment (vim/vim#19008)Interesting. On 9.1.1775 on the problem machine, I get the following via the reproducer:
- Pressing
i<C-a>inserts 0; a second press insertsitembefore the0.cci<C-a>insertsitem0(notitem?). - Repeated completions (C-x C-l C-x C-l) work just fine.
I'm still not sure what's going on with the 0 in item0, but it seems I should now be bisecting instead (still strange that this only affected my linux machine).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.