[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).
bug-5923-emacs.el
Description: Binary data
- bug#5923: 23.1.95; minibuffer-message discards input events, Drew Adams, 2010/04/10
- bug#5923: 23.1.95; minibuffer-message discards input events, Stefan Monnier, 2010/04/10
- bug#5923: 23.1.95; minibuffer-message discards input events,
Drew Adams <=
- bug#5923: 23.1.95; minibuffer-message discards input events, Stefan Monnier, 2010/04/13
- bug#5923: 23.1.95; minibuffer-message discards input events, Drew Adams, 2010/04/14
- bug#5923: 23.1.95; minibuffer-message discards input events, Drew Adams, 2010/04/19
- bug#5923: 23.1.95; minibuffer-message discards input events, Drew Adams, 2010/04/19
- bug#5923: 23.1.95; minibuffer-message discards input events, Drew Adams, 2010/04/20
- bug#5923: 23.1.95; minibuffer-message discards input events, Drew Adams, 2010/04/20
- bug#5923: 23.1.95; minibuffer-message discards input events, Drew Adams, 2010/04/20