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: Sun, 24 Mar 2002 16:50:43 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: <200203242350.g2ONoh122379@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 1017013173 15849 127.0.0.1 (24 Mar 2002 23:39:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 24 Mar 2002 23:39:33 +0000 (UTC) Cc: emacs-devel@gnu.org Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16pHaH-00047W-00 for ; Mon, 25 Mar 2002 00:39:33 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16pHi3-0003I2-00 for ; Mon, 25 Mar 2002 00:47:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16pHZz-0003T2-00; Sun, 24 Mar 2002 18:39:15 -0500 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 16pHXg-0003Os-00; Sun, 24 Mar 2002 18:36:54 -0500 Original-Received: (from dajo@localhost) by Rednose.Rhubarb (8.11.6/8.11.6) id g2ONoh122379; Sun, 24 Mar 2002 16:50:43 -0700 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.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2174 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2174 I have re-looked at this issue today with the following results. * Problem Summary: input-pending-p yields an incorrect value 50% of the time in emacs 21.1 and emacs-21.2 under some window managers. * Result Summary: I have been unsuccessful in solving the problem. I have made all the efforts that I can think of, with result that it appears that the problem lies in code called by get_input_pending in keyboard.c. The problem only occurs when running under some window managers. Truly simple demonstration code is not obvious. The complex demonstration code is available to anyone; this complex code is simple to install and uninstall. * My procedure was as follows. ** run under Gnome ** run one copy of emacs-21.1 as the testpiece ** run another emacs (which was emacs-21.2) running gdb, and attach the testpiece via its pid. ** do not use the mouse at all * Following this procedure gives the sequence of outputs from input-pending-p as t t t t t ... * Running the emacs-21.1 without gdb gives the sequence t nil t nil t ... * The sequence from emacs-21.1 running under twm is nil nil nil nil nil ... and this is correct under the test conditions. * The sequence from emacs-20.7 running under Gnome is nil nil nil nil nil ... and this is correct under the test conditions. * Thus (my) using gdb modifies the problem so that I am unable to make comparisons. * I put the following code into keyboard.c. This gives entirely consistent results with what is seen in lisp. I conclude that the problem lies in get_input_pending. /* this function is used below */ void FYS (str) char *str; { Lisp_Object dummy; Lisp_Object * dumref; dummy = build_string (str); dumref = &dummy; Fmessage (1, dumref); } DEFUN ("input-pending-p", Finput_pending_p, Sinput_pending_p, 0, 0, 0, "T if command input is currently available with no waiting.\n\ Actually, the value is nil only if we can be sure that no input is available.") () { if (!NILP (Vunread_command_events) || unread_command_char != -1) return (Qt); get_input_pending (&input_pending, 1); input_pending > 0 ? FYS("true") : FYS("false"); return input_pending > 0 ? Qt : Qnil; } * It is possible to upset the t nil t nil t ... sequence by using "tricks", in particular by inputting two keystrokes in rapid succession ("double-clicking" on the keyboard). But this leads me to no conclusion except to re-inforce the idea that the problem is a timing isue. I think that interrupt_input always is 1, causing the return from get_input_pending, at least in the attached emacs-21.1 case. static void get_input_pending (addr, do_timers_now) int *addr; int do_timers_now; { /* First of all, have we already counted some input? */ *addr = !NILP (Vquit_flag) || readable_events (do_timers_now); /* If input is being read as it arrives, and we have none, there is none. */ if (*addr > 0 || (interrupt_input && ! interrupts_deferred)) return; /* Try to read some input and see how much we get. */ gobble_input (0); *addr = !NILP (Vquit_flag) || readable_events (do_timers_now); } * Also I again looked into producing a simple example; I do not see how to do that. I can demonstrate, what really is deducible anyway, that the problem only occurs when I involve X: I have a toggle on the code that uses either popup frames or windows in the parent emacs; the latter continues to work perfectly. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel