From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: [CVS] f7, f8 bound.. Date: Thu, 29 Aug 2002 13:24:19 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200208291724.g7THOJZ11366@rum.cs.yale.edu> References: <87lm6xiruh.fsf@computer.localdomain> <5xu1liwmu6.fsf@kfs2.cua.dk> <200208261526.g7QFQX624783@rum.cs.yale.edu> <5xu1lgu1e4.fsf@kfs2.cua.dk> <200208271621.g7RGLNm30516@rum.cs.yale.edu> <5xhehfe3aj.fsf@kfs2.cua.dk> <5x4rdfdzu6.fsf@kfs2.cua.dk> <200208281413.g7SEDkT03872@rum.cs.yale.edu> <5xvg5thgw8.fsf@kfs2.cua.dk> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1030641927 5927 127.0.0.1 (29 Aug 2002 17:25:27 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 29 Aug 2002 17:25:27 +0000 (UTC) Cc: "Stefan Monnier" , Miles Bader , "D. Goel" , emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17kT2o-0001XJ-00 for ; Thu, 29 Aug 2002 19:25:22 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17kTZB-00022X-00 for ; Thu, 29 Aug 2002 19:58:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17kT4C-0004Tz-00; Thu, 29 Aug 2002 13:26:48 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17kT1u-0004FS-00 for emacs-devel@gnu.org; Thu, 29 Aug 2002 13:24:26 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17kT1r-0004Df-00 for emacs-devel@gnu.org; Thu, 29 Aug 2002 13:24:25 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17kT1p-0004Ay-00; Thu, 29 Aug 2002 13:24:21 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g7THOJZ11366; Thu, 29 Aug 2002 13:24:19 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: storm@cua.dk (Kim F. Storm) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:7121 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7121 > "Stefan Monnier" writes: > > > > Maybe it would be sensible to make this customizeable, e.g. > > > kmacro-call-repeat-key which defaults to `e' or ` ' or nil. > > > > I think repeating "the last key" is the best choice, in case the command > > is bound to something else than C-x e. Also this mimics the C-x z z z z > > behavior, so there's a precedent for it. > > I've implemented this. > > New custom variables are kmacro-call-repeat-key and > kmacro-call-repeat-with-arg so both you and Miles will be happy. > > In addition C-x e will now end the macro (like C-x )) if it is current > defining a macro rather than signalling an error. And you can repeat it > immediately with `e'... Thanks. That's just great! Hopefully the repeating behavior (whether with C-x e e e e or C-x e SPC SPC SPC) can be made the default, but at least now it's easy to turn it on. > > Because I don't want to see the interface I use (i.e. C-x (, C-x ) > > and C-x e) take second class status and have all the improvement go > > on F3 and F4 bindings. > > This is unfounded. I think I'm pretty receptive to the requests and > ideas from users to add features that I'd never use myself. Yes, but you wouldn't have thought about C-x e e e e yourself because you don't use that interface [ I fell like I'm not really defending my argument here ;-) ] > > I'd rather see the `edit-kbd-macro' kind of functionality > > improved/supplemented with something lighter weight so I can fix my macros > > "on the fly" as I see them fail (no I don't know what that would look > > like, sadly). > > That's a nice idea. > > Maybe something like "step through macro" with the ability: > > For each key sequence, ask user for confirmation: > > SPC to accept the last action and executes the next, > DEL to undo the last action and removes it from the macro, > C-x ( ... C-x ) allows you to add actions in the middle of the macro, and > RET simply accepts the rest of the macro. > > WDYT? As I said I had no idead what that could look like, but this suggestion sounds pretty good. Maybe something else than C-x ( ... C-x ) (for instance: any other binding is taken as "execute it and insert it in the macro"), so if I see that the macro failed, I can undo it, then step through it and when a step fails I just DEL + replacement... That sounds great. Stefan