[Top][All Lists]

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

Re: address@hidden: Lingering input pending with motif menu bar]

From: Kim F. Storm
Subject: Re: address@hidden: Lingering input pending with motif menu bar]
Date: Tue, 04 Jul 2006 11:08:12 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Chong Yidong <address@hidden> 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 (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 <address@hidden> http://www.cua.dk

reply via email to

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