[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: input-pending-p
From: |
David |
Subject: |
Re: input-pending-p |
Date: |
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
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: input-pending-p,
David <=