help-gnu-emacs
[Top][All Lists]
Advanced

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

proposed keyboard-macro to record to elisp (was Re: line-move-visual)


From: Joseph Brenner
Subject: proposed keyboard-macro to record to elisp (was Re: line-move-visual)
Date: Wed, 08 Dec 2010 15:12:42 -0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> IMO, that should be done automatically.  But others argue, that a
>> keyboard macro should act exactly as doing the same stuff manually. Then
>
> There's a tension here, indeed: OT1H keyboard macros only record
> a sequence of keys, so they should really be equivalent to having the
> user hit the same keys in the same order, but OTOH they correspond to
> mechanical execution, i.e. to code, so they need simple&reliable
> semantics in order to work well.
>
> As Emacs commands tend to get more complex over time (more DWIMish,
> usually), we have more cases of commands that should really only ever be
> used interactively because they require the user to see the result
> before making the next step.
>
> This tension for keyboard macros is made evident if you ever try to turn
> a keyboard macro into a piece of Elisp code.  A job which would seem
> simple enough that a little Elisp package could do it for you, right?
>
> I would encourage people to try and write up a new keyboard-macro
> package which would be closer to writing Elisp code: instead of
> recording keys, it would record commands, and would do so in a submode
> where DWIMish things (line-move-visual, abbrev-mode, auto-fill-mode,
> ... you name it) are disabled.

The existing keyboard-macro recorder is funky in a number of respects.

(1) saving your work is not the default, and in fact takes several
    additional steps that are not very obvious. I might suggest:

   (a) automatic naming of macros ("keyboard-macro-1", "keyboard-macro-2"...)
   (b) a standard init file where keyboard-macros accumulate:
       ~/.emacs.d/user-generated-macros.el

       alternately: a standard directory: ~/emacs.d/key-macros/,
       where macros are saved one-per-file, and old and unloved
       ones can be expired

   (c) a follow-on command to fixup macros you expect to use in the
       future, which encourages/simplifies the process of:
         o  renaming
         o  assign key binding
         o  documenting

(2) There's no easy way to recover from errors during macro recording.
    The user can type very carefully for hundreds of commands, and then
    a single mistake can trash all of their work and require starting
    from scratch.

(3) There is indeed too high a barrier between creating a keyboard-macro
    and converting it to emacs lisp code.  There's an easy way to do
    customizations (keyboard-macros) and a more powerful, but harder way
    (write elisp) and the user sees the switch between the two as a big
    leap.


reply via email to

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