[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.
Message not available
Re: line-move-visual, Stefan Monnier, 2010/12/08
Re: line-move-visual, Tassilo Horn, 2010/12/08
proposed keyboard-macro to record to elisp (was Re: line-move-visual),
Joseph Brenner <=
Re: proposed keyboard-macro to record to elisp (was Re: line-move-visual), LanX, 2010/12/08
Message not availableRe: line-move-visual, Xah Lee, 2010/12/08
Re: line-move-visual, Mark Crispin, 2010/12/09
Re: line-move-visual, Xah Lee, 2010/12/08
Message not availableMessage not availableRe: line-move-visual, Uday S Reddy, 2010/12/08
Re: line-move-visual, David Kastrup, 2010/12/08
Message not availableRe: line-move-visual, Alain Ketterlin, 2010/12/08
Message not availableRe: Wrong use of format=flowed antidote, Uday S Reddy, 2010/12/08
Re: line-move-visual, Joost Kremers, 2010/12/08
Message not availableRe: line-move-visual, Tassilo Horn, 2010/12/08