Re: input-pending-p

[David]

I think that I have found out the cause of this problem.  I *have*
found out how to solve the problem from my point of view.  Currently I
am testing to the extent possible.  Please be aware that I do not have
a comfortable grasp of what is happening in Emacs; what I write and
what I have done is inspired guesswork.

If you have any commentary I shall be pleased to receive it.  I am
especially interested in knowing if this problem will be addressed in
future releases.

It seems that Gnome/sawfish is fond of generating FOCUS_IN_EVENT
events (and other stuff - Emacs gets quite busy).  These events then
are put into the Emacs event queue and result in a positive yield from
input-pending-p when really there is nothing there.  The problem does
not arise with fvwm, twm, etc because they do not generate the
FOCUS_IN_EVENT events.

So far this patch has solved the problem for me.

patch for 21.2 keyboard.c

6245,6250c6245,6253
<       kbd_buffer_store_event (&buf[i]);
<       /* Don't look at input that follows a C-g too closely.
<        This reduces lossage due to autorepeat on C-g.  */
<       if (buf[i].kind == ascii_keystroke
<         && buf[i].code == quit_char)
<       break;
---
>       if (buf[i].kind != FOCUS_IN_EVENT)
>         {
>           kbd_buffer_store_event (&buf[i]);
>           /* Don't look at input that follows a C-g too closely.
>              This reduces lossage due to autorepeat on C-g.  */
>           if (buf[i].kind == ascii_keystroke
>               && buf[i].code == quit_char)
>             break;
>         }

dajo

>  - Function: input-pending-p
>      This function determines whether any command input is currently
>      available to be read.  It returns immediately, with value `t' if
>      there is available input, `nil' otherwise.  On rare occasions it
>      may return `t' when no input is available.
> 
> You might like to know that this function is, newly, giving me trouble
> so that the "rare occasions" occur exactly 50% of the time.  I am
> calling the function in small (1-5) bursts and the value yielded by
> input-pending-p is predictably and reliably nil on the odd-numbered
> calls and t on the even numbered calls.  Under the conditions that
> pertain the value always should be nil.
> 
> The code that, now, is failing is years old, has been in use
> sucessfully for years, and, what is interesting, now performs like
> this.
> 
> Emacs 20.7, window managers twm, fvwm, Gnome:  works properly
> Emacs 21.1, window managers twm, fvwm:         works properly
> Emacs 21.1, window managers Gnome, KDE:        fails as indicated
> It is difficult for me to check KDE and 20.7 at the moment.