[vim/vim] preinsert with autocomplete only inserts the longest completion (Issue #18314)

Char

unread,

Sep 16, 2025, 12:03:00 PM (2 days ago) Sep 16

to vim/vim, Subscribed

char101 created an issue (vim/vim#18314)

Steps to reproduce

set completeopt=menuone,preinsert autocomplete
type some text

I thought it would be interesting to have auto-completion candidate preinserted when typing, but trying preinsert with autocomplete results in only the longest text preinserted, even though completeopt does not contain longest.

hello
hella
he[ll] <- preinsert stops at ll

Expected behaviour

I expect preinsert to preinsert the first completion when autocomplete is running if completeopt does not contain longest.

Version of Vim

9.1.1754

Environment

Windows 10

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

unread,

Sep 16, 2025, 7:21:54 PM (2 days ago) Sep 16

to vim/vim, Subscribed

habamax left a comment (vim/vim#18314)

ping @girishji

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Char

unread,

Sep 16, 2025, 8:16:52 PM (2 days ago) Sep 16

to vim/vim, Subscribed

char101 left a comment (vim/vim#18314)

Another related issue is that selecting the next match in autocomplete inserts the whole text instead of preinserting it.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

girish

unread,

Sep 17, 2025, 12:43:58 AM (yesterday) Sep 17

to vim/vim, Subscribed

girishji left a comment (vim/vim#18314)

Have you read :h cot?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Char

unread,

Sep 17, 2025, 1:12:07 AM (24 hours ago) Sep 17

to vim/vim, Subscribed

char101 left a comment (vim/vim#18314)

I build my vim documentation into html so it is not always in sync with the latest documentation. I see now that it is there in the documentation.

The second problem still applies though

Selecting a completion entry inserts the text instead of preinserting it
What if I want the first selection to be selected like normal completion popup? I don't see the benefit of inserting the longest common prefix. Without preinsert, a longest common prefix can be typed after, but it can't be typed after in preinsert mode.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

girish

unread,

Sep 17, 2025, 1:45:15 AM (23 hours ago) Sep 17

to vim/vim, Subscribed

girishji left a comment (vim/vim#18314)

Without preinsert, a longest common prefix can be typed after, but it can't be typed after in preinsert mode.

Can you elaborate?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Char

unread,

Sep 17, 2025, 2:12:56 AM (23 hours ago) Sep 17

to vim/vim, Subscribed

char101 left a comment (vim/vim#18314)

In completion without preinsert, using longest will position the cursor after the longest prefix, after which I can type more characters to get more specific completion.

With preinsert, the longest prefix is just decoration.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Char

unread,

Sep 17, 2025, 2:22:42 AM (23 hours ago) Sep 17

to vim/vim, Subscribed

char101 left a comment (vim/vim#18314)

So far I can get vim to insert the first match using (local patch just for my personal use).

diff --git a/src/insexpand.c b/src/insexpand.c
index 9b21697f5..021b928fe 100644
--- a/src/insexpand.c
+++ b/src/insexpand.c
@@ -5921,13 +5921,15 @@ ins_compl_insert(int move_cursor, int preinsert_prefix)

     if (preinsert_prefix)
     {
-       cp_str = find_common_prefix(&cp_str_len, FALSE);
-       if (cp_str == NULL)
-       {
-           cp_str = find_common_prefix(&cp_str_len, TRUE);
-           if (cp_str == NULL)
-               return FAIL;
-       }
+       // cp_str = find_common_prefix(&cp_str_len, FALSE);
+       // if (cp_str == NULL)
+       // {
+           // cp_str = find_common_prefix(&cp_str_len, TRUE);
+           // if (cp_str == NULL)
+               // return FAIL;
+       // }
+       cp_str = compl_shown_match->cp_next->cp_str.string;
+       cp_str_len = compl_shown_match->cp_next->cp_str.length;

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

girish

unread,

Sep 17, 2025, 3:04:42 AM (22 hours ago) Sep 17

to vim/vim, Subscribed

girishji left a comment (vim/vim#18314)

With preinsert, the longest inserted suffix is just decoration.

set completeopt=menuone,preinsert ac
abccc
abddd
a|b <- can't type after b

When you type ^Y or b the cursor does not advance after b?

Also, what is the use case you have in mind? How do you intend to use this?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Char

unread,

Sep 17, 2025, 3:17:53 AM (22 hours ago) Sep 17

to vim/vim, Subscribed

char101 left a comment (vim/vim#18314)

When you type ^Y or b the cursor does not advance after b?

^Y: in autocomplete there is no selection yet
b: of course the cursor will advance if I type b but why would I do that since in normal completion with longest set I don't have to type b.

Also, what is the use case you have in mind? How do you intend to use this?

I want the normal set completeopt=menuone,preinsert behavior but with autocomplete trigger. Of course the selection is an issue, because in autocomplete the first entry is not selected while the normal completion will select the first entry.

Which is why I think it would be good if the preinsert text in autocomplete mode can be determined on whether completeopt has longest set. If longest is set in completeopt then show the longest common suffix, but if not show the first entry as preinsert. Personally I don't get any information from the longest common suffix as preinsert, I would prefer seeing the first match.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

girish

unread,

Sep 17, 2025, 4:50:09 AM (20 hours ago) Sep 17

to vim/vim, Subscribed

girishji left a comment (vim/vim#18314)

The current implementation addresses this use case: when there are many completions such as foobarabc, foobarxyz, foobarfoobaz, etc., typing f preinserts foobar. I can accept that with <C-y>, and then type one more letter to further filter the candidates. This significantly reduces typing. If no common prefix is found among all matches, it still pre-inserts the longest prefix from the current buffer — which is not the same as longest.

I’m not sure what use case you’re aiming to solve. For a autocomplete feature to add real value, it should reduce keystrokes. Simply preinserting the first item doesn’t achieve that.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Char

unread,

Sep 17, 2025, 9:10:37 AM (16 hours ago) Sep 17

to vim/vim, Subscribed

char101 left a comment (vim/vim#18314)

Having to press <C-y> to select the common suffix will actually increase the press required.

When I set preinsert, what I want is a preview of the first completion match, not to have to select the common suffix. To select the first match, I only have to press <Tab> (one keypress) which is a mapping I can set to select the first match. Having to select the common suffix will require at least two keypresses.

If I do want to select the common suffix first, I would add longest to completeopt.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

girish

unread,

Sep 17, 2025, 9:21:19 AM (16 hours ago) Sep 17

to vim/vim, Subscribed

girishji left a comment (vim/vim#18314)

Having to press <C-y> to select the common suffix will actually increase the press required.

Wrong. Read my previous post again about inserting 'foobar' in one step. You don’t always need to accept pre-inserted text when it’s inefficient.

When I set preinsert, what I want is a preview of the first completion match, not to have to select the common suffix. To select the first match, I only have to press <Tab> (one keypress) which is a mapping I can set to select the first match. Having to select the common suffix will require at least two keypresses.

Nothing prevents you from pressing <Tab> to select the first match, even when a prefix is preinserted. Simply map <Tab> to <C-N> when pumvisible() is true.

You still haven’t shown a case where preinserting the first match actually saves keystrokes. The first match is already visible at the top of the list—repeating it at the cursor is redundant.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Char

unread,

Sep 17, 2025, 9:24:21 AM (16 hours ago) Sep 17

to vim/vim, Subscribed

char101 left a comment (vim/vim#18314)

You still haven’t shown a case where preinserting the first match actually saves keystrokes.

You are missing the point. Preinserting the first match does not save keystores. I want to preinsert the first match because preinserting the longest common suffix is not useful to me. Like I said, I want the behavior of the normal completion menu, where the first match is preinserted.

Why even preinsert the longest common suffix unless I actually want to use <C-y> to select it?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

girish

unread,

Sep 17, 2025, 11:55:13 AM (13 hours ago) Sep 17

to vim/vim, Subscribed

girishji left a comment (vim/vim#18314)

That's what preinsert in normal completion do. Redundant to you but I actually want that redundancy. My eyes prefers the linear scanning over scanning the dropdown menu.

Fair enough. I'll put it on my todo list.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Char

unread,

Sep 17, 2025, 12:42:17 PM (12 hours ago) Sep 17

to vim/vim, Subscribed

char101 left a comment (vim/vim#18314)

I have used it for some time with my patch above and I found an interesting use case (for me), that is to use autocompletion with preinsert only without the popup menu, since most of the time I don't actually read the popup menu because it will disrupt the typing flow.

Setting pumheight=1 will effectively hide the popup menu when there is more than one entries.

Unfortunately the usual keys like <C-y> do not work in this case.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

girish

unread,

Sep 17, 2025, 1:17:03 PM (12 hours ago) Sep 17

to vim/vim, Subscribed

girishji left a comment (vim/vim#18314)

I have used it for some time with my patch above and I found an interesting use case (for me), that is to use autocompletion with preinsert only without the popup menu, since most of the time I don't actually read the popup menu because it will disrupt the typing flow.

Setting pumheight=1 will effectively hide the popup menu when there is more than one entries.

Unfortunately the usual keys like <C-y> do not work in this case.

Have you tried using ^1 in cpt, essentially limiting list to single item?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Char

unread,

Sep 17, 2025, 9:03:18 PM (4 hours ago) Sep 17

to vim/vim, Subscribed

char101 left a comment (vim/vim#18314)

I still want to use <C-p>/<C-n> to select another match.

The preinserted text can be considered a compact form of the completion menu. So if the preinserted text is shown, <C-p>/<C-n> could rotate the selected entry while <C-y> select the entry.

Currently by making f_pumvisible take the preinsert effect I can use <C-p>/<C-n>/<C-y> to select/complete the word.

    static void
f_pumvisible(typval_T *argvars UNUSED, typval_T *rettv UNUSED)
{
    if (pum_visible() || ins_compl_preinsert_effect())
	rettv->vval.v_number = 1;
}

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

girish

unread,

12:24 AM (1 hour ago) 12:24 AM

to vim/vim, Subscribed

girishji left a comment (vim/vim#18314)

I implemented a preinserted() Vimscript function to check whether text is preinserted. I didn’t include it in the PR because I didn’t find it particularly useful. It seems it is valuable.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Char

unread,

12:43 AM (19 minutes ago) 12:43 AM

to vim/vim, Subscribed

char101 left a comment (vim/vim#18314)

If you add a pumselected() (pum visible and has selection) function then preinserted() is implied by pumselected() && &completeopt =~ "preview". pumselected() might cover more bases than preinserted().

My two line patch above is really buggy because text can randomly appear. So I end up not using autocomplete but only preview. So I can press <Tab> to display the completion candidate as a preinserted text, press <Tab> to show the next match as the preinserted text, and press <Enter> to select the match. The problem is that sometimes there is an extra random character inserted after pressing <Enter>.