[vim/vim] Fix: Backspace does not clear selected item in insert-completion (PR #18265)
girish
Fix: Backspace does not clear selected item in insert-completion
Problem:
After selecting and inserting a completion item, pressing <BS> to delete part of the inserted text does not clear the selection.
- The completion item stays selected even though the text no longer matches.
- Pressing
<C-N>moves to the next item instead of restarting from the first. - If only one item is available,
<C-N>does nothing (buggy). - This differs from the behavior of other editors/IDEs.
Expected behavior:
Once the inserted text no longer matches the selected item, it should be deselected.
Notes:
This bug is also present in v9010754, so it may have been longstanding.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/18265
Commit Summary
- 1c25103 Fix: Backspace does not clear selected item in insert-completion
File Changes
(3 files)
- M src/insexpand.c (9)
- M src/testdir/test_ins_complete.vim (23)
- M src/testdir/test_popup.vim (4)
Patch Links:
—
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#18265)The completion item stays selected even though the text no longer matches.
How does the text no longer match? Even in your screnshot the text still matches.
—
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#18265)I don't think this is an improvement.
—
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#18265)There seems to be some inconsistency here. When pressing <bs> after one has selected some item from the pum and the list of matches is updated and includes more alternatives, the selected item vanishes. But if one presses <bs> and the list of matches does not change, then the selected item stays the same.
I don't have a preference either way, as long as we behave what is documented at popupmenu-keys (but it doesn't mention what should happen with the selected item). Actually there seem to be 3 different behaviours according to my short test.
E.g. what I mean is the difference in the this. With the following lines in a buffer (using vim --clean)
foobarfoo
foobar
foobarbaz
foobarbay
foobarb
pressing GA<C-N><Down><BS> -> keeps the selected item foobarbay
pressing GA<C-N><Down><BS><BS> -> selects a new item foobarbaz
pressing GA<C-N><Down><BS><BS><BS> -> updates the list of matches, removes the selection completly.
As far as I can see this behaves already like this on v9.0.0000.
—
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#18265)Example 1: Vim (--clean)
-
Start Vim:
vim --clean -c 'set cot=menuone' -
Type
foobar. -
On the next line, type
f<C-N>to open the completion menu. -
Press
<BS>twice to delete characters.
At this point, the menu shows the item selected but not matching the leader:
Screenshot.2025-09-10.at.6.22.48.PM.png (view on web)Now press <C-N>. Nothing happens because the previously selected item was deselected. The user just wasted a keystroke — a clear UX flaw.
Example 2: Neovim + nvim-cmp
The exact same scenario (as the original example) behaves correctly: the menu updates intuitively, item gets deselected after <BS>, and <C-N> works as expected.
Takeaway: The PR fixes a subtle but important UX issue, preventing wasted keystrokes and making completion behavior more predictable.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#18265)Nothing happens because the previously selected item was deselected.
Hmm, I won't call this "nothing happens", as that'll mean the selected item doesn't change either.
—
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#18265)Nothing happens because the previously selected item was deselected.
Hmm, I won't call this "nothing happens", as that'll mean the selected item doesn't change either.
From the user’s perspective, nothing happens. What matters is the behavior at the cursor, not the color of an item in a popup menu. This point isn’t up for debate.
Meanwhile, I don't see why one will have a reason to navigate the popup menu after deleting some characters if the menu items haven't changed.
You’re shifting the topic. Let’s stay focused—I don’t have time to go down unrelated paths.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#18265)You’re shifting the topic. Let’s stay focused—I don’t have time to go down unrelated paths.
If we don't know the circumstances where this happens, how can we decide the desired behavior?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18265)You’re shifting the topic. Let’s stay focused—I don’t have time to go down unrelated paths.
If we don't know the circumstances where one wants to do this, how can we decide the desired behavior?
Who exactly is “we”?
The correct behavior has already been established. Please review my earlier comments, including the Neovim example.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#18265)Who exactly is “we”?
Anyone who wants to decide what the correct behavior is.
The correct behavior has already been established. Please review my earlier comments, including the Neovim example.
I have read them and I don't think the correct behavior has been established. I have a different example:
:set completeopt=menuone,noselect- Trigger completion like your original example, but select a matching using
<Down>key instead of<C-N>, which doesn't insert the selected match - Typing
<C-L>adds a character from the current match, while typing<BS>removes a character from the current match
Before this PR, the current match doesn't change in step 3, while after this PR the current match changes when typing <BS>.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
gcanat
@gcanat commented on this pull request.
In src/insexpand.c:
> @@ -2602,6 +2606,11 @@ ins_compl_addleader(int c) return; } + // "preinsert" insertes the first match via compl_shown_match
small typo
⬇️ Suggested change- // "preinsert" insertes the first match via compl_shown_match + // "preinsert" inserts the first match via compl_shown_match
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
girish
@girishji pushed 1 commit.
- c1b72cc Update src/insexpand.c
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18265)Who exactly is “we”?
Anyone who wants to decide what the correct behavior is.
I referred to the first use of "we", not the last.
The correct behavior has already been established. Please review my earlier comments, including the Neovim example.
I have read them and I don't think the correct behavior has been established. I have a different example:
:set completeopt=menuone,noselect- Trigger completion like your original example, but select a matching using
<Down>key instead of<C-N>, which doesn't insert the selected match- Typing
<C-L>adds a character from the current match, while typing<BS>removes a character from the current match
Before this PR, the current match doesn't change in step 3, while after this PR the current match changes when typing
<BS>. On the other hand, there are more cases where the selected item doesn't match the inserted text that clearly aren't bugs.
This behavior is still correct in this PR, since the previous behavior revealed a UX flaw when dealing with a single item, as I mentioned above.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#18265)I referred to the first use of "we", not the last.
These two are the same.
This behavior is still correct in this PR
No it isn't.
Before:
https://github.com/user-attachments/assets/0e48ea29-d1c4-437f-8ccd-dedecaaa28d5
After:
https://github.com/user-attachments/assets/bec2fe4d-be06-45a0-94b6-4dbfc6559f0f
—
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#18265)The behavior implemented in this PR is correct, as it prevents a UX flaw. Neovim’s behavior is also correct, and the same reasoning applies to the Up/Down keys.
Consider a real-world example: when many matches are present and the scroll bar is active, user might select a match further down the list, causing the beginning of the menu to scroll out of view. If the user then deletes several characters (realizing that wasn’t the right match), the beginning of the list—where the most relevant results usually are—is no longer visible. At this point, pressing <C-n> won’t return to the top of the list; instead, it will select the next item relative to the previously chosen match, which is less relevant than the results at the beginning.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#18265)If the user then deletes several characters (realizing that wasn’t the right match), the beginning of the list—where the most relevant results usually are—is no longer visible.
- If deleting characters does not add more matches, why will the user delete several characters after they realize they selected the wrong match, when they can just select another match directly?
- If deleting characters does add more matches, I'd say it's more likely that the user mistook a match for a similar one (e.g. mistaking
foo47forfoo48in your screenshot), and similar matches are more likely to be grouped together.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18265)The example I described above is a real-world case I’ve personally run into several times, which is why I made this change. Now you’re trying to decide for the user how they should behave!
- If deleting characters does not add more matches, why will the user delete several characters after they realize they selected the wrong match, when they can just select another match directly?
Because I may not know the exact match I want yet—I just know the prefix I’d like to use as the starting point. Once I change that prefix, I expect the most relevant results for it.
- If deleting characters does add more matches
It doesn’t always, as the example illustrates.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#18265)The example I described above is a real-world case I’ve personally run into several times, which is why I made this change. Now you’re trying to decide for the user how they should behave!
No I'm not, because this is already the current behavior.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18265)I’d like to wrap up this discussion with a quick summary:
- This PR fixes two issues:
1. UX flaw ref
2. Localizing (sticking) to irrelevant context ref. - The behavior is consistent with Neovim ref.
With that in mind, I believe this PR should be merged.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#18265)It's possible that what's actually missing here is a way to quickly jump to the start of the the popup menu. With that it's easy to achieve to behavior introduced in this by with a mapping. On the other hand with this PR the old behavior is hard to achieve.
The behavior is consistent with Neovim
nvim-cmp is not Neovim.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
Shane-XB-Qian left a comment (vim/vim#18265)but the case to my side was selected item (after `<bs>`) sometimes was invisible,
this PR seems make it just de-selected? but what if user did not set `noselect` to `cot`?
looks this made it always *no* pre-selected when `<bs>`?
tho sometimes such case happened even no this PR, after `<bs>`, became no pre-selected somehow;
but compared to `sometimes` i preferred *not* `always`,
*or* would you make it pre-selected one and visible, when no `noselect` in `cot`?
--
shane.xb.qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
girish
@girishji pushed 2 commits.
- 57c5fe0 Apply this change only for autocompletion
- 116267d Merge branch 'badselect' of https://github.com/girishji/vim into badselect
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18265)It's possible that what's actually missing here is a way to quickly jump to the start of the the popup menu. With that it'll be easy to achieve to behavior introduced in this by with a mapping. On the other hand with this PR the old behavior is hard to achieve.
The behavior is consistent with Neovim
No it isn't. It's consistent with nvim-cmp, which IIRC reimplements the entire popup menu from scratch.
I suppose it is possible to provide a mechanism to deselect the item after <BS>. But I've constrained this change to autocompletion. It is simpler this way.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
girish
@girishji pushed 2 commits.
- 13fdca8 Remove redundant code
- 05f5d81 Merge branch 'badselect' of https://github.com/girishji/vim into badselect
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18265)I cannot seem to reproduce the problem here. It seems to work exactly the same with or without the patch. Same with this. I tried a few variations of hitting <c-n> going down until item 41 than backspacing a few characters. The selected item stays it is not removed and hitting <c-n> again does not start from the top again.
this also did not change.
So what am I doing wrong?
—
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#18265)I cannot seem to reproduce the problem here. It seems to work exactly the same with or without the patch. Same with this. I tried a few variations of hitting
<c-n>going down until item 41 than backspacing a few characters. The selected item stays it is not removed and hitting<c-n>again does not start from the top again. this also did not change.So what am I doing wrong?
Are you using :set autocomplete? In the last commit, I limited this change to affect only autocompletion.
—
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#18265)I see now, thanks.
—
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#18265)Hm, forgot to close. Fixed as of: 5c9b71d
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #18265.
—
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#18265)Thanks.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.