Re: [vim/vim] hit-enter prompt eats keys from a running mapping (PR #20753)

19 views
Skip to first unread message

zeertzjq

unread,
Jul 12, 2026, 3:14:17 AMJul 12
to vim/vim, Subscribed
zeertzjq left a comment (vim/vim#20753)

I think this change makes sense, considering that if a key dismisses a hit-enter prompt, it's only recorded if it's put back into the typeahead to be processes again in Normal mode.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/20753/c4950338849@github.com>

zeertzjq

unread,
Jul 12, 2026, 3:15:16 AMJul 12
to vim/vim, Subscribed
zeertzjq left a comment (vim/vim#20753)

I think this change makes sense, considering that if one dismisses a hit-enter prompt with <CR>, it's not recorded.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/20753/c4950341376@github.com>

dezza

unread,
Jul 13, 2026, 7:23:31 PMJul 13
to vim/vim, Subscribed
dezza left a comment (vim/vim#20753)

Happens with popup taking input like CR/Enter as well. If echomsg trigger hit-enter while popup is active the hidden hit-enter prompt will await input not the popup - making it require double CR/Enter

  • 1st press hidden hit-enter prompt dismissed.
  • 2nd press goes to popup.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/20753/c4963777183@github.com>

Christian Brabandt

unread,
Jul 19, 2026, 12:01:22 PMJul 19
to vim/vim, Subscribed
chrisbra left a comment (vim/vim#20753)

Hm, I wonder if the following change would make the popup filter case work then:

    else if (!stuff_empty() || !typebuf_typed()
#ifdef FEAT_PROP_POPUP
	    || popup_no_mapping()
#endif
	    )
	c = CAR;


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/20753/c5016390013@github.com>

XiaowenHu

unread,
Jul 20, 2026, 11:51:40 AMJul 20
to vim/vim, Subscribed
XiaowenHu96 left a comment (vim/vim#20753)
@chrisbra the fix can work and a patch is ready with a test case.
But before pushing it... I'm genuinely not sure what we are trying to provide here.
No hit-enter prompt when a filter is active?
How is that helpful to developers who want to see their debugging messages?

@dezza, what is the *hidden* prompt you are describing?
A minimal repro would help me understand the use case.


On Sun, Jul 19, 2026 at 09:00:50AM -0700, Christian Brabandt wrote:
> chrisbra left a comment (vim/vim#20753)
>
> Hm, I wonder if the following change would make the popup filter case work then:
>
> ```c

> else if (!stuff_empty() || !typebuf_typed()
> #ifdef FEAT_PROP_POPUP
> || popup_no_mapping()
> #endif
> )
> c = CAR;
> ```
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/vim/vim/pull/20753#issuecomment-5016390013
> You are receiving this because you authored the thread.
>
> Message ID: ***@***.***>


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/20753/c5024224299@github.com>

dezza

unread,
Jul 20, 2026, 1:12:13 PMJul 20
to vim/vim, Subscribed
dezza left a comment (vim/vim#20753)

@XiaowenHu96

" requires 2x <CR> to trigger, hit-enter owns input
nnoremap <buffer> <CR> <Cmd>echomsg 'reached'<CR>
call popup_menu(['one'], {})
redraw!
echomsg repeat('x', &columns * 2)


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/20753/c5024995622@github.com>

XiaowenHu

unread,
Jul 21, 2026, 4:25:59 AMJul 21
to vim/vim, Subscribed
XiaowenHu96 left a comment (vim/vim#20753)

@dezza I tried your repro:

0. vim -S repro_dezza.vim
1. see a hit-enter prompt and a popup
2. press <CR>, nothing happens
3. press <CR> again, prompt and popup both disappear

To me, something looks stale cuz between the first and the second <CR> the
screen does not change at all.

I then tried the following:

func Log(m)
  call writefile([a:m], 'events.txt', 'a')
endfunc

func Chosen(id, res)
  call Log('POPUP got CR -> result=' . a:res)
endfunc

call popup_menu(['one'], #{callback: 'Chosen'})
redraw!
echomsg repeat('x', &columns * 2)
0. vim -S repro_events.vim
1. see a hit-enter prompt and a popup
2. press <CR> -> events.txt is created with "POPUP got ..." but the screen does not change
3. press <CR> again -> prompt and popup both disappear

So my conclusion is the first <CR> goes to the popup, and the second one
dismisses the hit-enter prompt. Something is causing the screen to be stale and
nothing happens between the first and second <CR>.

I am not that familiar with this part of the code though, and I would assume this
staleness issue is already known? If not, I'm happy to look into it.
In any case it looks like a separate problem from what this PR fixes.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/20753/c5031752274@github.com>

dezza

unread,
Jul 28, 2026, 12:23:04 AMJul 28
to vim/vim, Subscribed
dezza left a comment (vim/vim#20753)

I just tried now with a FocusGained [Y/n] dialog where there were some errors meanwhile. Same symptom here, it needs 2 presses.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/20753/c5099913084@github.com>

XiaowenHu

unread,
Aug 14, 2026, 11:38:48 AM (2 days ago) Aug 14
to vim/vim, Subscribed
XiaowenHu96 left a comment (vim/vim#20753)

I've opened #21052 for @dezza's report, which I think is a separate issue.
Otherwise I think the patch is self-contained and ready to merge. @chrisbra


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/20753/c5295208086@github.com>

Reply all
Reply to author
Forward
0 new messages