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

[storm@cua.dk (Kim F. Storm)]

Richard Stallman <rms@gnu.org> writes:

>     Which reminds me that there is a big difference between replaying a keyboard
>     macro and running the corresponding functions as a single command:
>
>     - the pre-command-hook and post-command-hook are run for each key in
>     the keyboard macro, but only once for the single command.
>
>     This doesn't mean that the elisp code cannot be equivalent to the keyboard
>     macro, but it may be much harder to do right.
>
> There are various ideas of what is "right" for such a conversion.
> I think the converted code should ignore these hooks, and if the
> results are different, in most cases that will make sense.

Maybe, but there are many things that can go wrong...

Perhaps some of the work could be done by analyzing the undo
history ...

> Delete Selection mode is an exception.  In Delete Selection mode,
> if these hooks are not run, the results will clearly be wrong.
> The same may be true of CUA mode.

It is even more complex I think:

With CUA mode, the interpretation of C-x and C-c depends on 
whether the region is active or not.  That is not done through
pre-command-hook (but setting/extending the region is), but rather
through the keymaps which are active at the time.

> The conversion program could test for the presence of these specific
> hook functions in pre-command-hook, and generate appropriate code in
> the output Lisp function.  

This will only work if the conversion is done while recording the
keyboard macro - as one keystroke may modify the hooks.

>                            Rather than calling these hook functions
> before each command, it should call them only in the places where they
> would do real work.  And it wouldn't call the same function, but
> rather a related one.  Here's what it could look like:
>
> (put 'delete-selection-pre-hook 'lisp-conversion-function
>      (lambda (function)
>        (let ((type (and (symbolp this-command)
> 	                (get this-command 'delete-selection))))
> 	 (when type
> 	   `(delete-selection-pre-command-processing ,type)))))
>
> where `delete-selection-pre-command-processing' would be
> a new function that does the same work as `delete-selection-pre-hook'
> but gets `type' as an argument.

That might work.

IMO, the only real solution is to record the elisp code while recording
the keyboard macro - as it is possible to cather for changes in
the mark-active state and insert suitable set-mark commands etc.

Still, I fail to see the real need for the functionality.

It may be ok as a way to get a starting point for an editing command,
but only very trivial functions can be written that way anyway - and
they are just as well written and saved as a series of keystrokes as
they do now.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk