Return to Answer

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.

Without the C-f, the macro just zips through to executing the command.

[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]

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]

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.

Without the C-f, the macro just zips through to executing the command.

[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]

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.

Without the C-f, the macro just zips through to executing the command.

[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]

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 it is file being renamed---which is in a register--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.

Without the C-f, the macro just zips through to executing the command.

[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 change in question referencesminibuffer-follows-selected-frame, it would be good to check (or eliminate) any fancy behavour. FWIW, I have tested my suggestion using emacs -Q]

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.

Without the C-f, the macro just zips through to executing the command.

[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]