[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 27 May 2002 17:02:11 -0600
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
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
So far this patch has solved the problem for me.
patch for 21.2 keyboard.c
< 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)
> 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)
> - 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
> 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.
|[Prev in Thread]
||[Next in Thread]|
- Re: input-pending-p,