Emacs 28: How to use `RET` without exiting a recursive edit within a keyboard macro?

Question

Now that I switched to using GNU Emacs 28.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G95)) of 2022-05-11 I can no longer end my use of my keyboard macro that allows me to rename a file, by using the "Return/Enter" key (RET).

In that macro I enter a recursive edit (using C-u C-x q) to allow me to edit the file name and change it. I now have to use M-C c to terminate the recursive edit.

If I try to finish the recursive edit with RET I get an error Not in most nested command loop, and I have to use C-] to abort the recursive edit and regain use of the mini-buffer. I find that if I do use C-] in this manner, another RET will exit use of the mini-buffer and the file name is changed as desired.

Can this be fixed, or can I somehow work around it, to get back to being able to end the keyboard macro after using RET to enter a file name?

My keyboard macro is defined as follows:

(fset 'rn "wR\C-y\C-u\C-xq")

This is meant for use in a Dired buffer.

Answer 1

Try this,

  (defalias 'rn
    (kmacro "M-x r e n a m e - f i l e <return> C-x r i a <return> C-x r i a C-f"))

I assume that

• the register a contains the base file name, and
• the file being renamed----which is in register a----is the visited file.

The End of buffer error thrown by the C-f seems to help you edit the string. A subsequent RET does the rename.

Note that the macro definition doesn't enter recursive levels. Without the C-f, the macro just zips through to executing the command. My contention is that it should stay put in the minibuffer, waiting for "minibuffer exit" to arrive.

[Question: If the keystrokes that form the macro are typed manually, then after the second C-x r i a, you are still in mini-buffer because you haven't exited the mini-buffer yet. So, shouldn't the above kmacro, without the trailing C-f, also leave your cursor in the mini-buffer, and not exit it?

I am using kbd-macro-query for the first time. So, I don't have a reference on what the behaviour used to be. My gut feeling says that the kmacro shouldn't zip through to doing rename-file when you haven't exited the minibuffer.]

I am on emacs-29.0.50 (dtd. 2022-07-07), and kmacro uses oclosure-lambda, and so behaviour on Emacs 28.1 and my own Emacs 29.0.50 may not be directly compared. But, I do see the same exact behaviour as you do.

---

Btw, the error is coming from exit-minibuffer: minibuffer.el#L2452, and the commit in question is Make recursive minibuffers and recursive edits work together .

This (emacs-devel) Re: Stop frames stealing eachothers' minibuffers! message seems like a good starting point for further exploration.

[One more Question: Are you using helm etc., and have fancy customizations. Since the commit in question "somehow" concerns minibuffer-follows-selected-frame, it would be good to check (or eliminate) any fancy behavour. FWIW, I have tested my suggestion using emacs -Q]

Answer 2

This qualifies as comment ... Since there is too less a space to give elaborate comment, I am turning it to an answer.

I have emacs-gtk 27.1+1-3.1+b1 on Debian, and running it with -Q flag

• the second version is equivalent of what the original poster says. I confirm that after that the macro is paused with C-u C-x q, a simple edit and RET successfully does the rename.

• the first version, "the non-recursive version with C-f" exactly same as emacs-29.0.50 dtd .2022-07-07 Without the C-f, rename-file just zips through, and I am not offered an opportunity to edit. My contention is that it shouldn't zip through, because one hasn't done "minibuffer exit".

;; Note the `C-f` which makes the minibuffer stay put
(fset 'rn27-non-recursive
      (kmacro-lambda-form [?\M-x ?r ?e ?n ?a ?m ?e ?- ?f ?i ?l ?e return ?\C-x ?r ?i ?a return ?\C-x ?r ?i ?a ?\C-f] 0 "%d"))

(fset 'rn27-recursive
   (kmacro-lambda-form [?\M-x ?r ?e ?n ?a ?m ?e ?- ?f ?i ?l ?e return ?\C-x ?r ?i ?a return ?\C-x ?r ?i ?a ?\C-u ?\C-x ?q] 0 "%d"))