From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Francesco Potorti` Newsgroups: gmane.emacs.devel Subject: Re: [CVS] f7, f8 bound.. Date: Wed, 11 Sep 2002 11:03:06 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: 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> <200208291724.g7THOJZ11366@rum.cs.yale.edu> <5xd6roult6.fsf@kfs2.cua.dk> <87ptvmavj2.fsf@pot.cnuce.cnr.it> <5xadmpv3j3.fsf@kfs2.cua.dk> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1031735098 22218 127.0.0.1 (11 Sep 2002 09:04:58 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 11 Sep 2002 09:04:58 +0000 (UTC) Cc: emacs-devel@gnu.org, deego@glue.umd.edu, miles@gnu.org, monnier+gnu/emacs@rum.cs.yale.edu, rms@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 17p3Qe-0005mE-00 for ; Wed, 11 Sep 2002 11:04:56 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17p41U-0006Mm-00 for ; Wed, 11 Sep 2002 11:43:00 +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 17p3Qk-0000kU-00; Wed, 11 Sep 2002 05:05:02 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17p3P6-0000iy-00 for emacs-devel@gnu.org; Wed, 11 Sep 2002 05:03:20 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17p3P4-0000im-00 for emacs-devel@gnu.org; Wed, 11 Sep 2002 05:03:20 -0400 Original-Received: from pot.cnuce.cnr.it ([146.48.83.182]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17p3P3-0000ig-00; Wed, 11 Sep 2002 05:03:17 -0400 Original-Received: from pot by pot.cnuce.cnr.it with local (Exim 3.35 #1 (Debian)) id 17p3Os-0002eU-00; Wed, 11 Sep 2002 11:03:06 +0200 Original-To: storm@cua.dk (Kim F. Storm) In-reply-to: <5xadmpv3j3.fsf@kfs2.cua.dk> (storm@cua.dk) X-fingerprint: 4B2 6187 5C3 D6B1 2E31 7666 9DF 2DC9 BE21 6115 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:7846 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7846 > That is only part of the problem. It often occurs to me that, while I'm > defining a long macro, I make a mistake in the middle of it. > > The current behaviour is discarding the work done so far, so I have to > restart from the beginning. > > The behaviour Richard proposes is to stop recording the macro (without > discarding it), so I'd have to restart with a series of undos, in order > to get rid of the modifications I did with the interrupted macro > definition, then restart with C-uC-x(, which reexecutes the macro > defined so far and then allows me to continue defining it. Also, this > requires some thinking, because after doing the undo and the redo I must > be careful to remember where exactly I had made a mistake. You can use C-u C-u C-x ( to append to the macro without re-executing it first. I suppose this is a new feature, because the current pretest does no exhibit this behaviour (nor does it document it). It is useful, indeed. Also look at `kmacro-execute-before-command'. If you set it to nil, you can use C-u C-x ( to append to the previous macro without re-executing it. You can look at the defined macro with C-x C-k C-v. You can also experiment with the new step-edit feature on C-x C-k SPC. These are all useful features, but they are not easy nor obvious to use. You must know about them, you must learn how to use them, you must remember them once you have learned. I, for one, usually write some complex macros once in a while. It may happen that I do not write one for some months, and then I spend some days writing many. Non-obvious features are forgotten in the meantime. The suggestion Miles made (below) allows the whole range of choices at the cost of a single question, and then only when you make an error. It cannot be annoying, because the fact itself of making an error somehow breaks your thought direction. The advantage is that it immediately allows you to resume, without any other thinking, and it requires no learning at all. > Generally speaking, the possible choices one would want are: > - aborting the definition (the current behaviour) > - ending the definition with or without the last command > - continuing the definition with or without the last command > > As Miles says, however, only one question is needed: > Error occured; ignore last command? (y or n) > without interrupting the recording of the macro. > > This would leave the user the whole range of choices: they can abort > with C-g, they can continue, they can end with C-x), and they can choose > whether they want the last command included.