From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: [simon.marshall@misys.com: Lingering input pending with motifmenu bar] Date: Tue, 4 Jul 2006 14:21:02 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1152048095 7010 80.91.229.2 (4 Jul 2006 21:21:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Jul 2006 21:21:35 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 04 23:21:33 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 1FxsKl-0007Dr-9d for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2006 23:21:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FxsKk-0002oO-GR for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2006 17:21:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FxsKZ-0002o5-Hb for emacs-devel@gnu.org; Tue, 04 Jul 2006 17:21:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FxsKW-0002nc-VZ for emacs-devel@gnu.org; Tue, 04 Jul 2006 17:21:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FxsKW-0002nZ-Sa for emacs-devel@gnu.org; Tue, 04 Jul 2006 17:21:12 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FxsYH-0004uM-N4 for emacs-devel@gnu.org; Tue, 04 Jul 2006 17:35:25 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k64LLBNT013392 for ; Tue, 4 Jul 2006 16:21:11 -0500 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-73-192.vpn.oracle.com [141.144.73.192]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k64LL93h023370 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Jul 2006 15:21:10 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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:56529 Archived-At: 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 the right way to wait N seconds, we should make sit-for do this, so that user programs don't have to use a complex work-around. If this indeed works right, then I think putting this into sit-for is a clear bug-fix. Would you like to do it? Please make sure that all possible user events are treated. I don't know if Chong meant to include mouse wheel in "mouse clicks", but wheel movement should be included as a user event that ends `sit-for'. Likewise, drag events (which aren't clicks either). Also, at least some of the special events (`special-event-map') are user events (e.g. iconify-frame, delete-frame). Even though the doc of `sit-for' speaks of input events, I wonder if there isn't perhaps some existing code that expects `sit-for' to also stop waiting for other, non-user events. We shall see... Also, if we fix `sit-for' this way, would something similar need to be done for code that sets variables such as `last-input-event'? I'm guessing that here and there current code already tries to distinguish user events, and it might need updating to use the correct approach. IOW, maybe the same approach should be used elsewhere. Because the exact list of events that are user-initiated might change (e.g. over releases), I wonder if it would be worth defining `user-event' as a type (category) of events and `user-event-p' as its test. Then, any code that deals with this would use that, and the exact set of user events would only be updated in one place. Is the `sit-for' bug fix to be made before the release?