From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#6256: 24.0.50; read-event in `repeat' command Date: Mon, 24 May 2010 08:11:37 -0700 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1274715185 18767 80.91.229.12 (24 May 2010 15:33:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 24 May 2010 15:33:05 +0000 (UTC) To: 6256@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 24 17:33:02 2010 connect(): No such file or directory Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OGZe6-00063J-0w for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 May 2010 17:32:59 +0200 Original-Received: from localhost ([127.0.0.1]:47729 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGZcl-0004TW-3B for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 May 2010 11:31:27 -0400 Original-Received: from [140.186.70.92] (port=34478 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGZZ3-0003M2-Ru for bug-gnu-emacs@gnu.org; Mon, 24 May 2010 11:31:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGZYg-00019J-DL for bug-gnu-emacs@gnu.org; Mon, 24 May 2010 11:27:17 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44593) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGZYg-00019C-7q for bug-gnu-emacs@gnu.org; Mon, 24 May 2010 11:27:14 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OGZKw-00026S-Ip; Mon, 24 May 2010 11:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 May 2010 15:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 6256 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: Original-Received: via spool by submit@debbugs.gnu.org id=B.12747139628073 (code B ref -1); Mon, 24 May 2010 15:13:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 24 May 2010 15:12:42 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGZKc-00026A-AZ for submit@debbugs.gnu.org; Mon, 24 May 2010 11:12:42 -0400 Original-Received: from mx10.gnu.org ([199.232.76.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGZKZ-000265-8M for submit@debbugs.gnu.org; Mon, 24 May 2010 11:12:40 -0400 Original-Received: from lists.gnu.org ([199.232.76.165]:53885) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1OGZKU-0007u8-93 for submit@debbugs.gnu.org; Mon, 24 May 2010 11:12:34 -0400 Original-Received: from [140.186.70.92] (port=60303 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGZKR-0003Wm-8T for bug-gnu-emacs@gnu.org; Mon, 24 May 2010 11:12:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGZKP-0007lr-9m for bug-gnu-emacs@gnu.org; Mon, 24 May 2010 11:12:31 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:43118) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGZKO-0007lV-MI for bug-gnu-emacs@gnu.org; Mon, 24 May 2010 11:12:29 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4OFCLJD004748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 24 May 2010 15:12:24 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4O80bQC008442 for ; Mon, 24 May 2010 15:12:10 GMT Original-Received: from abhmt015.oracle.com by acsmt354.oracle.com with ESMTP id 262668871274713874; Mon, 24 May 2010 08:11:14 -0700 Original-Received: from dradamslap1 (/141.144.160.26) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 May 2010 08:11:10 -0700 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: Acr7U2eLNMl3f5XOTxOtwKcH93l1zw== X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090202.4BFA9759.00F3:SCFMA922111,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 24 May 2010 11:13:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:37226 Archived-At: In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-05-23 on G41R2F1 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include' I use popup frames a lot. By default, that is how a buffer gets displayed in my setup. I'm also on MS Windows, which has the property that a newly created frame is always selected (obtains the focus). This means that displaying a buffer is different, depending on whether its frame already exists. If it does, then the focus (typically) does not change to the buffer's frame. If it does not, then the focus moves there. I work around this focus-grabbing annoyance sometimes by using `select-frame-set-input-focus' at appropriate places. (Ugh!) Anyway, the problem I have is with the `repeat' command. Presumably, it tries to be sensitive to actual user events, such as typing a character, but ignore other, non-user events. This does not work for me in some cases - an automatic `switch-frame' event is causing it to stop repeating. I have a command that displays a buffer in its own frame (the same frame or another, possibly new, frame). I make it repeatable using `repeat', and I bind it to a key, say `f'. That works fine in general: hitting `f f f...' continues to display buffers - in new frames or existing frames. No problem. But in some cases my command also pops up an additional buffer, in another frame. In those cases the repetition breaks as soon as that second buffer is displayed. Hitting `f' at that point just inserts an `f' character (in that buffer if it was selected, else in the first buffer displayed by `f'). It does not matter whether the second buffer and its frame already exist or not. I mentioned the frame focus above, but that is apparently not the problem. It does not matter whether the `f' command opens the first buffer in a new frame or an existing frame, and likewise for the second buffer. And it does not matter whether the second buffer is selected (and its frame focused) or not. It is only when hitting `f' opens also a second buffer that a subsequent `f' just inserts. However, if I make a copy of the definition of command `repeat' and change only its `read-event' to `read-char-exclusive', then the problem goes away. So some event being read is being tested and found to be different from the `f' last input event, thus ending the repetition. I'm guessing that this is what happens: The `read-event' reads the `f' and repeats the command, which displays the first and second buffers. I would think there would be a `switch-frame' event associated with each buffer display, but maybe not. In any case, if there is a `switch-frame' for the first buffer display it is ignored, but the `switch-frame' for the second buffer display causes repetition to stop. It is difficult to use the debugger with `repeat', so I copied the code and inserted a call to `message' after the `read-event'. It shows clearly that display of the second buffer causes the event read to be a `switch-frame'. Do we intentionally use `read-event' here (instead of `read-char-exclusive') in order to let `repeat' work with other user events besides just char input (e.g. mouse clicks)? If so, then changing `read-event' to `read-char-exclusive' would not be the correct fix, but what would? This is not clear to me. `read-event' has been present in this code since at least Emacs 20, but this code does not correctly handle `switch-frame' events. Real user events need to be distinguished from events such as `switch-frame' that can be generated by code. Is changing `read-event' to `read-char-exclusive' the proper fix for this bug? It works for me. If it is not the right fix, then what is? If it is important for some use reason to keep `read-event', and no fix is found that would DTRT to distinguish real user events from events such as `switch-frame', then could we at least use `(funcall repeat-read-function)' instead of `(read-event)', so that code that wants to be sensitive to only char events can bind `repeat-read-function' to `read-char-exclusive' around the call to `repeat'? The default value of such a var could be `read-event', if that's deemed the best default, but we at least need some way to make `repeat' ignore non-char events (if we cannot find a way to make it ignore non-user events).