Re: [simon.marshall@misys.com: Lingering input pending with motif menu bar]

[storm@cua.dk (Kim F. Storm)]

Chong Yidong <cyd@stupidchicken.com> writes:

> As the Hanoi program runs, it checks (input-pending-p), and quits if
> input is detected.  The trouble is that when you invoke hanoi with the
> menubar, on some toolkits, (input-pending-p) gets triggered even when
> there is no input arriving.
>
> 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.

For example, try this:

GNU Emacs 22.0.50.67 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)

emacs -Q
M-x hanoi

Move the mouse to a tool-bar button or outside the emacs frame.

Hanoi quits.


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.

> Maybe someone who's worked on sit-for and/or the no-toolkit menu code
> can enlighten us.  Why does the input-pending-p get triggered, and is
> there any way to distinguish between a real input event and a fake
> one?  (Checking unread-command-chars or last-input-event doesn't
> work).

There is code to ignore FOCUS_IN events in readable_events.
Maybe we can extend the list to include more events.
But we may want to actually process some of those events.

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk