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