From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: input-pending-p Date: 06 Jun 2002 00:00:32 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5xofepbd33.fsf@kfs2.cua.dk> References: <200203070326.g273Q6A02247@Rednose.Rhubarb> <200203102132.g2ALWnX04173@wijiji.santafe.edu> <200205272302.g4RN2Bm06859@Rednose.Rhubarb> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1023313682 25940 127.0.0.1 (5 Jun 2002 21:48:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 5 Jun 2002 21:48:02 +0000 (UTC) Cc: rms@gnu.org, 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 17FidO-0006kH-00 for ; Wed, 05 Jun 2002 23:48:02 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17Fixw-0000Eu-00 for ; Thu, 06 Jun 2002 00:09:19 +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 17Fiaj-0006Lm-00; Wed, 05 Jun 2002 17:45:17 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17Fht8-0002CY-00; Wed, 05 Jun 2002 17:00:16 -0400 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id 5ECB87C016; Wed, 5 Jun 2002 20:59:48 +0000 (GMT) Original-To: dajo@a-vip.com In-Reply-To: <200205272302.g4RN2Bm06859@Rednose.Rhubarb> Original-Lines: 86 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:4593 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4593 David writes: > 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. Hi David, >From your analysis, it does indeed seem like excessive FocusIn events are confusing emacs. However, your patch is a bit radical (as it effectively ignores those events). Please try the following patch to see if it solves the problem. This is from the latest CVS version, but should apply directly to 21.2. Remember to undo your own patch before testing. Index: xterm.c =================================================================== RCS file: /cvs/emacs/src/xterm.c,v retrieving revision 1.735 diff -c -r1.735 xterm.c *** xterm.c 28 May 2002 20:27:59 -0000 1.735 --- xterm.c 5 Jun 2002 20:53:20 -0000 *************** *** 10784,10790 **** f = x_any_window_to_frame (dpyinfo, event.xfocus.window); if (event.xfocus.detail != NotifyPointer) dpyinfo->x_focus_event_frame = f; ! if (f) { x_new_focus_frame (dpyinfo, f); --- 10784,10790 ---- f = x_any_window_to_frame (dpyinfo, event.xfocus.window); if (event.xfocus.detail != NotifyPointer) dpyinfo->x_focus_event_frame = f; ! if (f && f != dpyinfo->x_focus_frame) { x_new_focus_frame (dpyinfo, f); ++kfs > > > - 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. > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://mail.gnu.org/mailman/listinfo/emacs-devel > >