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

[Chong Yidong]

> Would someone please DTRT and ack?
>
> I can reproduce this with --with-x-toolkit=MOTIF, but not LUCID.  Note that
> Motif is provided by Solaris.  I don't have GNU/Lesstif (sp?) to try it
> with.  Fingers crossed that this is also the cause of some other oddities
> I've seen with the menu bar that I've not been able to document enough to
> report...
>
> src/emacs -Q
> Options > Enter Debugger on Quit/C-g
> Tools > Games > Towers of Hanoi
>
> I get split windows, with the top of the *Hanoi* buffer in the upper window
> and the *Backtrace* buffer in the lower window, containing:

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.

so this is not necessarily the fault of input-pending-p, but it is
still annoying and problematic.  I have checked that sit-for also
suffers from the same problem (i.e., if Hanoi is recoded to run while
(sit-for foo) is t, the sit-for gets interrupted spuriously.)

I can see this happening reliably when Emacs is compiled with no X
toolkit; it doesn't happen with GTK.

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