[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: address@hidden: Lingering input pending with motifmenu bar]
From: |
Drew Adams |
Subject: |
RE: address@hidden: Lingering input pending with motifmenu bar] |
Date: |
Tue, 4 Jul 2006 10:03:10 -0700 |
> The Elisp manual entry for input-pending-p says
> On rare occasions it may return `t' when no input is available.
This is inaccurate! It happens all the time.
Problem is that input-pending-p simply indicates that there is
some unprocessed event in the queue -- not necessarily something
the user entered by pressing a key or clicking a mouse button.
I haven't looked to see what specific events are in the queue
in the above cases, but maybe it is a help-echo and "leave" event.
Is this perhaps related? `handle-switch-frame' shows up as a user command. I
use a separate frame for each buffer, and I have a standalone minibuffer. As
a result of this virtual user "command", I end up doing things like this in
my code:
(if (memq last-command (list this-command 'handle-switch-frame))...
Logically, I just want to check if the current user command is the same as
the previous one. But because of automatically inserted
`handle-switch-frame' entries, I need to pollute the test to deal with those
also. Note that the `handle-switch-frame' can arise without the user doing
anything (that I can see) - without, for instance, using the mouse or
keyboard to switch frames. I get the impression that even if the program
itself changes frame focus for some reason, a `handle-switch-frame'
"command" is inserted in the command history.
I haven't traced this in detail, to try to understand it, but it is annoying
and it makes the code less readable. I don't know if this is by design or a
bug. I imagine that there are good reasons why `handle-switch-frame' shows
up in the command history. I'm just pointing out that it makes my code more
cumbersome.
Please don't ask for a test case or scenario - I don't have time to do that
now. If this rings a bell, and you can enlighten me about this, fine; I'd
like to understand it better. If not, please ignore.
- Re: address@hidden: Lingering input pending with motif menu bar], (continued)
- Re: address@hidden: Lingering input pending with motif menu bar], Kim F. Storm, 2006/07/04
- Re: address@hidden: Lingering input pending with motif menu bar], Chong Yidong, 2006/07/04
- Re: address@hidden: Lingering input pending with motif menu bar], Richard Stallman, 2006/07/04
- RE: address@hidden: Lingering input pending with motifmenu bar], Drew Adams, 2006/07/04
- Re: address@hidden: Lingering input pending with motifmenu bar], Richard Stallman, 2006/07/05
- RE: address@hidden: Lingering input pending withmotifmenu bar], Drew Adams, 2006/07/05
- Re: address@hidden: Lingering input pending withmotifmenu bar], Richard Stallman, 2006/07/07
- Re: address@hidden: Lingering input pending with motifmenu bar], Richard Stallman, 2006/07/05
- Re: address@hidden: Lingering input pending with motif menu bar], Chong Yidong, 2006/07/04
- Re: address@hidden: Lingering input pending with motif menu bar], Kim F. Storm, 2006/07/05
- RE: address@hidden: Lingering input pending with motifmenu bar],
Drew Adams <=
Revamping sit-for [Was: Lingering input pending with motif menu bar], Chong Yidong, 2006/07/07
- Re: Revamping sit-for, David Kastrup, 2006/07/07
- RE: Revamping sit-for [Was: Lingering input pending with motif menu bar], Drew Adams, 2006/07/07
- Re: Revamping sit-for, Chong Yidong, 2006/07/07
- RE: Revamping sit-for, Drew Adams, 2006/07/07
- Re: Revamping sit-for, Chong Yidong, 2006/07/08
- Re: Revamping sit-for, David Kastrup, 2006/07/08
- Re: Revamping sit-for, Romain Francoise, 2006/07/08
- Re: Revamping sit-for, Stefan Monnier, 2006/07/08
- RE: Revamping sit-for, Drew Adams, 2006/07/08