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: Tue, 19 Oct 2010 15:17:45 -0700 Message-ID: <02C729C63ABB48A898C742329EE4ADB0@us.oracle.com> References: <058F2FC300154C1AB894694655B2A968@us.oracle.com><90A72397ABF34D84A3ACB3B6DE18F74A@us.oracle.com><0658C0CCC79D466BA9DE233F5980CAE5@us.oracle.com><8E5430CB43B84B91BB47DB3C0C710C44@us.oracle.com> 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 1287528170 4780 80.91.229.12 (19 Oct 2010 22:42:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 19 Oct 2010 22:42:50 +0000 (UTC) Cc: 6256@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 20 00:42:49 2010 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 1P8KtH-0004nj-A9 for geb-bug-gnu-emacs@m.gmane.org; Wed, 20 Oct 2010 00:42:43 +0200 Original-Received: from localhost ([127.0.0.1]:37365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P8KtG-0001G8-GQ for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Oct 2010 18:42:42 -0400 Original-Received: from [140.186.70.92] (port=42570 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P8KtA-0001G3-2P for bug-gnu-emacs@gnu.org; Tue, 19 Oct 2010 18:42:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P8Kt8-0007m9-NP for bug-gnu-emacs@gnu.org; Tue, 19 Oct 2010 18:42:35 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P8Kt8-0007m4-K0 for bug-gnu-emacs@gnu.org; Tue, 19 Oct 2010 18:42:34 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1P8KXL-0005Yj-Bm; Tue, 19 Oct 2010 18:20:03 -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: Tue, 19 Oct 2010 22:20:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6256 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6256-submit@debbugs.gnu.org id=B6256.128752674421350 (code B ref 6256); Tue, 19 Oct 2010 22:20:03 +0000 Original-Received: (at 6256) by debbugs.gnu.org; 19 Oct 2010 22:19:04 +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 1P8KWO-0005YJ-3W for submit@debbugs.gnu.org; Tue, 19 Oct 2010 18:19:04 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P8KWM-0005Xx-Uk for 6256@debbugs.gnu.org; Tue, 19 Oct 2010 18:19:03 -0400 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9JMMkrV025396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Oct 2010 22:22:47 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9JIi1Es017964; Tue, 19 Oct 2010 22:22:44 GMT Original-Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 703726631287526667; Tue, 19 Oct 2010 15:17:47 -0700 Original-Received: from dradamslap1 (/10.159.219.37) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 19 Oct 2010 15:17:47 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Actvz+FbQMTKGifUR7aQz1+ky5T4sgAA5nHQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 19 Oct 2010 18:20:03 -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:40996 Archived-At: > > 3. Your current read-key fix for `repeat' does not work in Emacs 23, > > whereas my fix using read-event does work. > > I did not understand that from your answer and I'm very > surprised, since > AFAIK this part of Emacs hasn't changed significantly. In > any case I've > only tested it under Emacs-23 (yup, that's a 3 there). > > > But maybe I will be if I understand its advantages. What was your > > objection to the solution I provided using `read-event'? You never > > stated it, IIRC. > > Your characterization of what works and what doesn't makes no sense to > me (based on my understand of what the code does, and based on my > tests), so I used the code that I know to work and I understand why. > > Since you say it doesn't work for you, please follow my advice: > > Please confirm whether or not it fixes it > for you, and if it doesn't, please show me the values of > `repeat-repeat-char' and `evt' in the above test. > > because without that info from your tests, I can't help you > much further. I tried debugging it that way. I added this just after the (let ((evt (read-key))), that is BEFORE the `and' test of the `while': (message "EVT: %S, R-R-CHAR: %S" evt repeat-repeat-char) In my own Emacs setup (which has lots of stuff in it) `C-x p wheel-down' moves correctly to the first bookmark, but then subsequent wheel-downs just start scrolling the window. IOW, `repeat' is exited immediately - there is no repetition at all. And because it exits immediately _no_ debug message appears in *Messages*. That tells me that it exited during `read-key', not because the event/key tested did not match (`while' test = nil). Apparently `read-key' itself exits out to the `unwind-protect' protection code in this scenario. I tried fiddling with `read-key-delay' but that didn't help. I used 3 bookmarks, all in the same buffer, so there should be no switch-frame events interfering anywhere. I do use a standalone minibuffer in my setup, and that sometimes causes `handle-switch-frame' events to happen in places one might not expect. But I don't think that is happening here (we are not even using the minibuffer, and everything should be taking place in the same frame). Dunno what is causing the problem. In emacs -Q, however, with just the Bookmark+ files loaded, I do not see the problem. That is presumably what you are seeing. The only way I see a problem then (without my setup) is if I rotate the wheel more rapidly. That is no doubt because it gets a `double-wheel-down' or `triple-wheel-down' event instead of a `wheel-down' event. I haven't bound those events specifically to the bookmark-cycling command, but I could do so to get around that (assuming that's the cause). For the same reason, I can see that same rapid-rotation problem with the fix I sent. This rapid-rotation behavior is not an issue, for me. The issue is the behavior I see when I use my own setup, and I cannot begin to pare things down from that setup to determine just what else might be involved. Presumably the bad behavior has something to do with how `read-key' works - something is apparently causing it to barf, but how `read-key' works is unclear to me. I hope that you (who wrote it) can figure out or guess what's happening here. I would have guessed that if there were a problem it would have occurred because `read-key' did not return an event/key that matched - like the problem with the original code and with the `read-char-exclusive' attempt I made first to fix it. But no, it never even got to the `and' test of the `while': it seems to have exited during `read-key'. Perhaps you can suggest something I can do to determine what is happening that causes it (presumably) to exit the `while' during the `read-key', jumping out to the `unwind-protect'. Is there some debug message I can put at the beginning of the the `unwind-protect' protection code to see what happened? Can I put some debug stuff into `read-key'? Coming back to my question - I see no problems at all when I instead use the solution I sent, which uses read-event instead of read-key. It just works. You still have not said anything about what's wrong with that solution. If your read-key solution worked I would not hesitate to say fine, let's go with it - believe me. But it doesn't. If we can figure it out and fix it, I'm OK with that. I'm willing to try to help determine what's going wrong with the `read-key' approach, if we can do that by just debugging the `repeat' code (as opposed to my trying to narrow down my setup). Again (coming back to my question), this is what I suggested: (while (let ((evt (read-event))) (and (equal (event-basic-type evt) (event-basic-type repeat-repeat-char)) (equal (event-modifiers evt) (event-modifiers repeat-repeat-char)))) (repeat repeat-arg)) It's pretty simple. It also seems logical, and it says just what we want to be done: if the event's components are all the same as before then repeat. Dunno why you have a problem with this. What problems do you see with this approach?