I hope every completion done inside minibuffer is repeatable by vertico-repeat, including commands invoked by M-x. Vertico, however, didn’t include execute-extended-command as a repeatable session by default. You can be seen it by examining vertico-repeat-filter variable. So I have to customize it like this in Doom Emacs:
(after! vertico-repeat
(setq vertico-repeat-filter (remove 'execute-extended-command vertico-repeat-filter)))
The question is execute-extended-command seems to be a reasonable default completing session, why does vertico excludes it?
One of the strengths of vertico is its modularity and compatibility with builtin APIs. Unfortunately, this also makes it difficult to restore a vertico session because vertico does not have access to the full completion state in the way that more monolithic completion packages like helm and ivy do. Some of it might even be created through a series of function calls which would be hard to reconstruct.
I would guess that vertico is not always able to repeat extended commands properly and so they are disabled by default. Unfortunately, vertico-repeat is fairly limited. Check out this post for more information. https://www.reddit.com/r/emacs/s/TV1Asbrhel
Minad (the vertico author) made some attempts at a better repeat extension but they all have various limitations. I ended up making my own repeat extension but it had issues as well so I’ve since abandoned it.
Unfortunately, if you must have such a feature in full generality, I’d recommend that you use helm or ivy instead. Personally, I’ve just learned to live with it as the advantages of the vertico stack are worth it IMO.
One should also mention the relatively new
vertico-suspendcommand. It takes a different approach via recursive minibuffers, but has its own limitations.I would guess that vertico is not always able to repeat extended commands properly and so they are disabled by default.
No, see my other answer.
Unfortunately, if you must have such a feature in full generality, I’d recommend that you use helm or ivy instead.
Ivy and Helm do not support repeating arbitrary completion sessions in full generality - because it is hardly possible. Only the state of commands which go through the ivy-read or helm API can be fully reconstructed.
Ivy and Helm do not support repeating arbitrary completion sessions in full generality - because it is hardly possible. Only the state of commands which go through the ivy-read or helm API can be fully reconstructed.
They do for commands that are defined with the ivy and helm framework. The downside of course is that everything has to be rewritten using their frameworks in order to have first class support. This is also necessary if you want other features such as actions and is one of the biggest disadvantages of using them.
They do for commands that are defined with the ivy and helm framework. The downside of course is that everything has to be rewritten using their frameworks in order to have first class support.
Yes, exactly.
This is also necessary if you want other features such as actions…
No this is not necessary. Embark supports actions for commands based on
completing-read.
execute-extended-commandis excluded for the reason that I didn’t find it useful to repeat. If you type M-x you get the recently used commands sorted to the top anyway. As an often executed command, M-x pollutes thevertico-repeat-history. You can browse the history withvertico-repeat-select. But if you dislike this default, it is easy to customize it.