Keyboard macro and default M-x command selection

[yantar92]

Hi,

I am trying the following:

1. M-x butterfly RET (so that it comes up first in the completion list next time I invoke M-x)
2. F3 M-x RET yes RET F4
3. Switch to sratch
4. C-x C-k n test RET
5. M-x insert-kbd-macro
6. Observe

    (defalias 'test
   (kmacro "M-x <return> y e s <return>"))

7. M-x eval-buffer RET
8. M-x test
9. Observe execute-extended-command: ‘’ is not a valid command name

Interestingly, running the macro with F4 works fine.
I am wondering if it is something on vertico side or on Emac side.

[minad]

It is not clear to me what the problem is, but the repeated M-x invocations will mess up the history (eval-buffer, test). If I bind 'test to a key, it works as well as F4 (assuming that butterfly is at the top).

[minad]

There is no issue in your recipe. I get the following when evaluating it:

Error in post-command-hook (vertico--exhibit): (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")
Error in pre-command-hook (vertico--prepare): (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")
execute-extended-command: ‘’ is not a valid command name

You only managed to create an infinite kmacro loop which overflows the stack. The stack trace looks like this:

... many repeated macro invocations ...
  (funcall-interactively test 1)
  (command-execute test record)
  (execute-extended-command nil "test" nil)
  (funcall-interactively execute-extended-command nil "test" nil)
  (command-execute execute-extended-command)
  (execute-kbd-macro [134217848 return 121 101 115 return] 1 kmacro-loop-setup-function)
  (test 1)
  (funcall-interactively test 1)
  (command-execute test record)
  (execute-extended-command nil "test" nil)
  (funcall-interactively execute-extended-command nil "test" nil)
  (command-execute execute-extended-command)
  (execute-kbd-macro [134217848 return 121 101 115 return] 1 kmacro-loop-setup-function)
  (test 1)
... many repeated macro invocations ...

[yantar92]

You only managed to create an infinite kmacro loop which overflows the stack

True.

There is no issue in your recipe

I'd say that it is a usability issue from user perspective. Usually, macros work reliably and recording them does not require changes in the usual way we execute commands in Emacs. However, the normal vertico workflow with using navigation to select command does require special attention from users, which is surprising.

It is indeed not a bug, but something that would be nice to improve.

[minad]

No, I do not agree. To be clear - there is neither an issue, nor a "usability issue", nor a reliability issue, nor something to improve here. You can as easily create an infinitely looping kmacro with default completion as you can with Vertico:

(defalias 'test (kmacro "M-x t e s t <return>"))

[minad]

One thing we could maybe consider is to opt-out of Vertico at all when doing kmacro recording or execution. Maybe this is what you mean by improvement? This can be done in vertico--setup by checking defining-kbd-macro or executing-kbd-macro. Will this lead to a better behavior in your opinion?

[yantar92]

That sounds reasonable. I just checked source code of execute-extended-command, and is has huge chunks of the code skipped completely when executing-kbd-macro is non-nil. So, disabling a interactive features during macro execution is something Emacs itself does.

[minad]

Okay, let's do this then. During macro recording/execution we better want 100% deterministic behavior while during interactive use we want dynamic updates, sorting by recency/frecency and so on, so it makes sense to distinguish these scenarios.

[minad]

Done in b413071

[minad]

However now that I've implemented the change I am not so convinced anymore. If you type M-x test RET in Vertico it is just as deterministic as default completion. The only difference now is that the user interactivity is not available anymore, e.g., the RET in your recipe is disabled. Let's wait for user feedback and maybe revert.