RE: address@hidden: Lingering input pending with motifmenu bar]

[Drew Adams]

    > 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.