[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on emacs keyboard macros

From: Stefan Monnier
Subject: Re: Comments on emacs keyboard macros
Date: Thu, 15 Feb 2001 10:30:55 -0500

>     (defun foo-example ()
>       (isearch-forward-regexp "^n")
>       (beginning-of-line)
>       (forward-word)
>       (copy-to-register-compatibility-binding ?1)
>       (command next-line))

I agree that it could be neat.  Although I see a few problems because
functions used in elisp are often different from functions used
interactively.  F.e.x I know of no elisp code that calls
`isearch-forward-regexp' or `copy-to-register-compatibility-binding'.

It's already too common to see elisp code using things like `next-line'
when they really mean `forward-line'.

[ as for recording command names rather than keys: sometimes recording
  keys is wrong when you switch to a different mode, but sometimes
  it's exactly what we want (when the mode uses a different command
  bound to the same key to do (conceptually) the same thing.
  Admittedly, in most such cases, we try to make the binding standard
  and use an additionaly indirection to allow the major-modes to
  provide their own version of the command (ex. indent-line-function,
  comment-start, ...). ]

> (2) I often create long complex keyboard macros that are not easy to
>     express quickly in Emacs Lisp, and am frequently stymied by a call
>     to (error "...") which aborts the keyboard macro collection.
>     Usually, the error call happens because I mistyped a search
>     string, or sometimes, a command name.  Then, the only recourse is
>     to start over.  This restart sometimes has to be done several
>     times, because I'm a fumble-fingered typist, and I also field a
>     lot of external interrupts from door knocks and telephone rings.
>     Would it possible to redefine error during keyboard macro
>     collection in such a way that it produced a soft error that didn't
>     abort the macro collection?

Along the same lines, it would be good to redefine `undo' such that
it removes the previous command from the recorded sequence of commands.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]