From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: [simon.marshall@misys.com: Lingering input pending with motif menu bar] Date: Tue, 04 Jul 2006 09:45:45 -0400 Message-ID: <87mzbp8ovq.fsf@stupidchicken.com> References: <87d5cmnpe7.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1152020787 7799 80.91.229.2 (4 Jul 2006 13:46:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Jul 2006 13:46:27 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 04 15:46:25 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FxlE4-0003e0-1G for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2006 15:46:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FxlE3-0001Oq-Hw for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2006 09:46:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FxlDr-0001OF-BA for emacs-devel@gnu.org; Tue, 04 Jul 2006 09:45:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FxlDq-0001O6-Lw for emacs-devel@gnu.org; Tue, 04 Jul 2006 09:45:50 -0400 Original-Received: from [18.72.1.2] (helo=south-station-annex.mit.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FxlRX-00082i-1N; Tue, 04 Jul 2006 09:59:59 -0400 Original-Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k64Djl8E027797; Tue, 4 Jul 2006 09:45:48 -0400 (EDT) Original-Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by grand-central-station.mit.edu (8.13.6/8.9.2) with ESMTP id k64DjlCj025266; Tue, 4 Jul 2006 09:45:47 -0400 (EDT) Original-Received: from cyd (SYDNEYPACIFIC-SEVENTY-FOUR.MIT.EDU [18.95.5.74]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id k64Djjmk016080; Tue, 4 Jul 2006 09:45:45 -0400 (EDT) Original-Received: from cyd by cyd with local (Exim 3.36 #1 (Debian)) id 1FxlDl-0000le-00; Tue, 04 Jul 2006 09:45:45 -0400 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Tue, 04 Jul 2006 11:08:12 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-Spam-Score: 1.47 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:56492 Archived-At: > Problem is that input-pending-p simply indicates that there is > some unprocessed event in the queue -- not necessarily something > the user entered by pressing a key or clicking a mouse button. > > I haven't looked to see what specific events are in the queue > in the above cases, but maybe it is a help-echo and "leave" event. > >> Maybe someone who's worked on sit-for and/or the no-toolkit menu code >> can enlighten us. Why does the input-pending-p get triggered, and is >> there any way to distinguish between a real input event and a fake >> one? (Checking unread-command-chars or last-input-event doesn't >> work). > > There is code to ignore FOCUS_IN events in readable_events. > Maybe we can extend the list to include more events. > But we may want to actually process some of those events. I've found a Lisp-level workaround --- by using `read-event' and `with-timeout', it's possible to catch just the events we are interested in (i.e., mouse clicks and keystrokes). It took quite a long time to find something that works, though. If this is an acceptable solution, the Elisp manual node on "Waiting" could be updated to mention this hack. *** emacs/lisp/play/hanoi.el.~1.19.~ 2006-05-09 10:08:04.000000000 -0400 --- emacs/lisp/play/hanoi.el 2006-07-04 09:44:24.000000000 -0400 *************** *** 399,407 **** ;; update display and pause, quitting with a pithy comment if the user ;; hits a key. (defun hanoi-sit-for (seconds) ! (sit-for seconds) ! (if (input-pending-p) ! (signal 'quit '("I can tell you've had enough")))) ;; move ring to a given buffer position and update ring's car. (defun hanoi-ring-to-pos (ring pos) --- 399,409 ---- ;; update display and pause, quitting with a pithy comment if the user ;; hits a key. (defun hanoi-sit-for (seconds) ! (if (= 0 seconds) ! (sit-for 0) ! (if (with-timeout (seconds nil) ! (read-event)) ! (signal 'quit '("I can tell you've had enough"))))) ;; move ring to a given buffer position and update ring's car. (defun hanoi-ring-to-pos (ring pos)