From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Newsgroups: gmane.emacs.devel Subject: Re: input-pending-p Date: Mon, 27 May 2002 17:02:11 -0600 Sender: emacs-devel-admin@gnu.org Message-ID: <200205272302.g4RN2Bm06859@Rednose.Rhubarb> References: <200203070326.g273Q6A02247@Rednose.Rhubarb> <200203102132.g2ALWnX04173@wijiji.santafe.edu> Reply-To: dajo@a-vip.com NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1022540565 27597 127.0.0.1 (27 May 2002 23:02:45 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 27 May 2002 23:02:45 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17CTVl-0007B0-00 for ; Tue, 28 May 2002 01:02:45 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17CTnI-00042D-00 for ; Tue, 28 May 2002 01:20:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17CTWJ-00013X-00; Mon, 27 May 2002 19:03:19 -0400 Original-Received: from dajo.ppp.frii.com ([216.17.133.250] helo=Rednose.Rhubarb) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17CTTC-0000vk-00; Mon, 27 May 2002 19:00:08 -0400 Original-Received: (from dajo@localhost) by Rednose.Rhubarb (8.11.6/8.11.6) id g4RN2Bm06859; Mon, 27 May 2002 17:02:11 -0600 Original-To: rms@gnu.org In-Reply-To: <200203102132.g2ALWnX04173@wijiji.santafe.edu> (message from Richard Stallman on Sun, 10 Mar 2002 14:32:49 -0700 (MST)) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4448 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4448 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.