[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5923: 23.1.95; minibuffer-message discards input events

From: Drew Adams
Subject: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Sat, 10 Apr 2010 12:59:48 -0700

> > Prior to Emacs 23, a user can hit `C-RET' after `C-u' and while
> > `[prefix (4)]' is displayed, and the `sit-for' is interrupted and
> > the action is executed immediately. Starting with Emacs 23, the
> > `C-RET' is ignored. A `C-RET' doesn't take effect until the
> > `sit-for' timeout is finished (as if it were `sleep-for').
> I can't reproduce exactly your test case because I don't know 
> what code is run by your C-u (and because I'm on GNU/Linux,
> ...), but at least when I start "emacs23 -Q" and do C-x C-f
> TAB TAB, the first tab outputs a minibuffer-message but the
> second TAB is executed immediately (interrupts the
> minibuffer-message).  So I don't see that problematic
> behavior you're seeing.
> Can you check whether my test case works for you as well?

I confirm that your test case works for me also.
The second tab has its effect - it is not lost.

[However, the minibuffer message remains displayed for the full timeout period.
That seems wrong - why not stop displaying the msg as soon as the tab event
arrives? Unless `Complete but not unique' is perhaps redisplayed by another call
or something?

IOW, after the second tab, *Completions* is shown, indicating that the tab did
take effect, and the message `Complete but not unique' is briefly removed -
replaced by the message `Making completion list...'. But the `Complete but not
unique' message then reappears for the duration of the `minibuffer-message'
timeout. Is this the behavior you see also?

Anyway, this is not the problematic behavior I get with my code, and which this
bug report is about.]

Attached is the code I use for `C-u' in the minibuffer. I hope it helps.

I should have mentioned that the same problem occurs when I use `C-u' in the
minibuffer at any time, not just in the scenario where I follow it by `C-RET'.
IOW, it has nothing to do with the particular user event that follows.

And as I said, in Emacs 22 and before there is no such problem: any user event
immediately interrupts the message display and its timeout, and no such event is
lost (so you don't need to hit the key multiple times).

Attachment: bug-5923-emacs.el
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]