Re: Is there a plan to record kbd macro as elisp code?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> Thank you for your appreciation. But my modification is in the C code of
>>> emacs, because 'execute-command' and 'call-interactively' are in C code.
>>> And I don't think my dirty code would be a valid patch for the emacs
>>> developers.
>> 
>> I think what was expected was to first record a keyboard macro and later to
>> turn that into elisp code.

> That's was exactly my first attempt when I tried to implement this feature.
> However, this approach doesn't work because a macro highly depends on its
> context, and will fail when repeating it in different buffers, modes, etc.

I think this doesn't matter: the same holds for the keyboard macros
themselves and yet they're quite usable.  The limitation of the approach
(that the macro needs to be converted to Elisp in the same context where it
was recorded) doesn't seem to be too serious: at least not a show-stopper.

OTOH I do expect that it can be very tricky to recover the structure from
just the key sequence: e.g. after a keybinding that may or may not present
a minibuffer prompt, figuring out whether the rest of the keys were sent to
the minibuffer or to the next command can be impossible without guessing.

>> Another approach is to use a pre-command-hook to record the value of
>> `this-command' for each command run.

> After failing with the first approach, I tried to do this, but this doesn't
> work because `this-command' doesn't record the arguments of the last
> command.  So when I added a new variable `this-command-args' that records
> the arguments of the command being executed, this approach produced
> good results.

> Also I added a new variable `last-kbd-macro-commands', and a new command
> `insert-last-kbd-macro-commands' to convert the recorded commands with
> their arguments to a Lisp function.  A change in isearch was also required
> to convert all isearch subcommands into one search function.

> Since yzhh doesn't want to post his code, I will post mine.
> I ask yzhh to comment on this code, compare with his own,
> and suggest further improvements:

This doesn't sound too bad.  Another approach would be to advise
`call-interactively'.

This may require changes at the C level so as to make sure that calls to
Fcall_interactively are never made directly but always go through the
`call-interactively' symbol.

With an exhaustive around advice on call-interactively, you should be
able to get a fairly reliable trace.

But even a reliable trace will encounter the problems mentioned by Kim, and
in order to get /good/ Elisp code (rather than just /working/ Elisp code),
a fair bit of post-processing will be needed with ad-hoc rewrites.


        Stefan