From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Behavior of `this-command-keys' Date: Tue, 12 Sep 2006 00:13:13 +0200 Message-ID: References: <87hczel26d.fsf@vh213602.truman.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1158012885 4457 80.91.229.2 (11 Sep 2006 22:14:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 11 Sep 2006 22:14:45 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 12 00:14:42 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 1GMu2z-00009y-Nk for ged-emacs-devel@m.gmane.org; Tue, 12 Sep 2006 00:14:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMu2z-0001cU-4z for ged-emacs-devel@m.gmane.org; Mon, 11 Sep 2006 18:14:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GMu2m-0001bn-DN for emacs-devel@gnu.org; Mon, 11 Sep 2006 18:14:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GMu2j-0001ZP-Dg for emacs-devel@gnu.org; Mon, 11 Sep 2006 18:14:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMu2j-0001ZB-6l for emacs-devel@gnu.org; Mon, 11 Sep 2006 18:14:17 -0400 Original-Received: from [195.41.46.235] (helo=pfepa.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GMu45-0001i4-GP for emacs-devel@gnu.org; Mon, 11 Sep 2006 18:15:41 -0400 Original-Received: from kfs-l.imdomain.dk.cua.dk (0x503e2644.bynxx3.adsl-dhcp.tele.dk [80.62.38.68]) by pfepa.post.tele.dk (Postfix) with SMTP id 4C594FAC012; Tue, 12 Sep 2006 00:14:16 +0200 (CEST) Original-To: belanger@truman.edu In-Reply-To: <87hczel26d.fsf@vh213602.truman.edu> (Jay Belanger's message of "Mon\, 11 Sep 2006 12\:54\:02 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:59714 Archived-At: Jay Belanger writes: > The behavior of `this-command-keys' doesn't seem to match its > documentation; perhaps I'm misunderstanding something. No, you have found a rather nasty bug. > Consider something like: > (defun test () > (interactive) > (sit-for 1) > (setq result (this-command-keys))) > (global-set-key "a" 'test) > To me, it sounds like as if `result' should equal "a" (the key which > calls the function) if "ab" were pressed, whether or not the `sit-for' > had run its course. However, `result' equals "a" or "ab" depending on > how close together the "a" and "b" are pressed. Since sit-for calls read-event internally, the result depends on whether you type the b while sit-for is inside read-event or not. That is obviously a bug. As far as I can see, we need a non-destructive version of read-event (wait-for-input SECONDS) But we almost have that: (while-no-input (sleep-for SECONDS)) The only problem is that a selection event will interrupt while-no-input. This is very annoying - also for other purposes than this. What can we do? -- Kim F. Storm http://www.cua.dk