Re: Native compilation of Keyboard Macros

[Juri Linkov <juri@linkov.net>]

>> 1. at level of complex command execution, such as from the history
>>    retrieved by `repeat-complex-command` (C-x ESC ESC), for example:
>>
>>    (rgrep "macro" "* .*" "emacs/lisp/")
>>
>> 2. at level of commands corresponding to all typed keys,
>>    such as retrieved by `view-lossage` (C-h l),
>>    for example, for the same as above:
>>
>>    M-x                ;; execute-extended-command
>>    r                  ;; self-insert-command
>>    g                  ;; self-insert-command
>>    r                  ;; self-insert-command
>>    <tab>              ;; minibuffer-complete
>
> Intuitively I would expect the first level to make more sense, though I
> see that when considering commands like `self-insert-command' you
> couldn't just deduce all the command invocations and wrap them in a
> `progn' body.  At the same time, what is there to compile on the second
> level?  You still need to look up all the commands and invoke them.  As
> Stefan said, it is perhaps necessary to either detect what commands can
> be safely converted into repeat-complex-command'-esque representations
> (and what commands can be assisted/transformed), and only optimise if
> that is possible.

Keyboard macros are executed on the keys level, so even the decision
what complex command to execute might depend on the position of that
command in the completion list of `M-x', e.g.:

      M-x        ;; execute-extended-command
      r          ;; self-insert-command
      <tab>      ;; minibuffer-complete
      <kp-prior> ;; switch-to-completions
      <tab>      ;; next-completion
      <tab>      ;; next-completion
      <tab>      ;; next-completion
      <tab>      ;; next-completion
      <return>   ;; choose-completion