On converting from kbd macro to elisp code

On converting from kbd macro to elisp code

[Herbert Euler]

I saw this in etc/TODO:

** Add a way to convert a keyboard macro to equivalent Lisp code.

Questions:

1. If keybindings are changed, the same keyboard macro may mean
   different operations.  Shall it be correct to convert a keyboard
   macro to Lisp code that does exactly the same things as in the old
   keybindings, or to convert a keyboard according to new keybindings?

2. Even if keybindings are not changed, the same keyboard macro may
   mean different operations for different major modes and/or minor
   modes.  Does each mode need a conversion?

Regards,
Guanpeng Xu

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: On converting from kbd macro to elisp code

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Sep 07, 2006 at 06:29:20PM +0800, Herbert Euler wrote:
> I saw this in etc/TODO:
> 
> ** Add a way to convert a keyboard macro to equivalent Lisp code.
> 
> Questions:
> 
> 1. If keybindings are changed [...]

> 2.  [...] different operations for different major modes [...]

IOW early versus late binding of keybindings (and modes?

(Sorry, I could not resist ;-)

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFAAG7Bcgs9XrR2kYRAoEUAJ9bxXu6RsNqe3t8NP5+lSTNgA+dVwCfaYsu
24sicRA2xvO2glQFLcS5vNw=
=LjZH
-----END PGP SIGNATURE-----

Re: On converting from kbd macro to elisp code

[Richard Stallman]

    1. If keybindings are changed, the same keyboard macro may mean
       different operations.  Shall it be correct to convert a keyboard
       macro to Lisp code that does exactly the same things as in the old
       keybindings, or to convert a keyboard according to new keybindings?

It should convert based on the current key bindings.
So if you typed C-f, it should call forward-char.

    2. Even if keybindings are not changed, the same keyboard macro may
       mean different operations for different major modes and/or minor
       modes.  Does each mode need a conversion?

Again, it should operate based on the current bindings.
The point is to produce nice-looking Lisp code
that could be a good start for hand-editing.

Re: On converting from kbd macro to elisp code

[Stuart D. Herring]

>     2. Even if keybindings are not changed, the same keyboard macro may
>        mean different operations for different major modes and/or minor
>        modes.  Does each mode need a conversion?
>
> Again, it should operate based on the current bindings.
> The point is to produce nice-looking Lisp code
> that could be a good start for hand-editing.

I've been considering working on this.  It has occurred to me that there
are several other uncertainties:

 - If the macro switches buffers/modes, even the bindings current at the
time of invocation may not be the only ones relevant.  It seems
particularly useless to not parse [ ?\M-x ?c ?+ ?+ ?\C-m ?\C-c ?\C-q ] to
(progn (c++-mode) (c-indent-defun)); similarly [ ?\C-x ?d ... ] should
obviously do something with Dired's commands.
 - Many functions behave differently if called interactively (e.g.,
printing messages that may be the point of the macro).  Do we want to use
`call-interactively' to try to mimic the actual results of the macro? 
(Of course, for things that prompt for arguments, `call-interactively' is
the wrong answer.  Some commands could have their INTERACTIVE arguments
passed...).
 - If a macro does completion in the minibuffer or so, is the generated
Lisp supposed to include what such completion might produce if attempted
at the time when (and in the possibly-entirely-unrelated environment in
which) the Lisp is generated?  Of course, the macro does the completion
at run time; should the Lisp then delay its attempt at completion until
it is run?
 - Similarly, a macro may use default arguments (e.g., from history
lists).  Should the generated Lisp use (at translation time) what they
would be if the macro were run then, or discover what the defaults are at
run time?
 - This is getting somewhat abstruse, but what about macros that invoke
the minibuffer but then switch out of it and continue editing?  Is that
supposed to generate
  ;; At this point the macro started to invoke `find-file'.
  (let ((defaults-for-next-command ...)) (other-buffer) ...
     ;; Now the macro finally commits its arguments:
     (find-file (nth ... defaults-for-next-command)))
?  Obviously, with recursive minibuffers things could get worse.
 - There is in general no way to discover what calls to `completing-read'
and such that a command (discovered via a key sequence in the macro that
may or may not precede arguments) might make without actually executing
it.  Even `interactive' specs that are in fact lists are automatically
unanalyzable; I note that such basic things as `load-file' and
`revert-buffer' have those.

The net result, as far as I can tell, is that all but the most naïve
interpretations of keyboard macros must be done by watching them execute
rather than via static analysis.  I see that `this-command' is set even
when `pre-command-hook' is being run, so I suppose a very rudimentary Lisp
translation could be made via that hook.

However, minibuffer arguments would still pose quite a problem; perhaps it
would be best if there was some sort of (optionally-run) tracing code in
`execute-kbd-macro' (or rather, in command_loop_1()) itself.  Perhaps the
command-handling code could make a series of simple calls to a Lisp
logging interface ("minibuffer entered", "command run: blah") that could
later assemble it into sensible Lisp.  Or it might make sense to use
`call-interactively', since it already generates `command-history'.

Thoughts?  Suggestions?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.