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: read-event in `repeat' command Date: Sun, 23 May 2010 15:37:09 -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 1274654329 448 80.91.229.12 (23 May 2010 22:38:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 23 May 2010 22:38:49 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 24 00:38:47 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@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 1OGJok-0007ub-1N for ged-emacs-devel@m.gmane.org; Mon, 24 May 2010 00:38:46 +0200 Original-Received: from localhost ([127.0.0.1]:36982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGJoj-0004Yj-6Z for ged-emacs-devel@m.gmane.org; Sun, 23 May 2010 18:38:45 -0400 Original-Received: from [140.186.70.92] (port=55746 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGJoa-0004YP-MG for emacs-devel@gnu.org; Sun, 23 May 2010 18:38:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGJoY-0002No-NG for emacs-devel@gnu.org; Sun, 23 May 2010 18:38:36 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:20021) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGJoY-0002Nj-IM for emacs-devel@gnu.org; Sun, 23 May 2010 18:38:34 -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 o4NMcUAk021189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 23 May 2010 22:38:32 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4NMUJsg019245 for ; Sun, 23 May 2010 22:38:29 GMT Original-Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 260817751274654203; Sun, 23 May 2010 15:36:43 -0700 Original-Received: from dradamslap1 (/141.144.88.29) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 23 May 2010 15:36:43 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acr6yHqnb06MJyfbQfmausYkBW+JKA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090203.4BF9AE69.0080:SCFMA922111,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:125154 Archived-At: 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'm writing about 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. Currently, 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'. Now I imagine that we intentionally use `read-event' here in order to let `repeat' work with other user events besides just char input (e.g. mouse clicks), so that changing `read-event' to `read-char-exclusive' would not be the correct fix. Can someone please help with this question? How can we get the fail-safe behavior of `read-char-exclusive' but without also eliminating repeated non-char user events such as mouse clicks? Or is `read-char-exclusive' in fact the right fix? I'm not clear about this. Suggestions welcome. Thx.