Occasionally I start to open a file, and before I select the file for some reason I execute C-x o before answering the prompt. Then everytime I try and run
find-file again it complains about Command attempted to use minibuffer while in minibuffer. However if I use a command like
isearch-forward-regexp, (even if already in a
find-file prompt), the error is not thrown and I can't switch back to the minibuffer using
Why is it that some prompts temporarily upgrade the minibuffer so that
other-window considers the minibuffer a possible target, and others do not?
Just to clarify, I’m not asking how to get unstuck.
Originally when I encountered this, I would switch to the minibuffer and do Esc Esc Esc or C-g to escape the prompt, so that I could initiate a new command that uses the minibuffer. However, on pondering this question, I realized that
abort-recursive-edit (C-]) will close this minibuffer in progress without having to do
Still, I'm not quite sure what the original use case is for. Perhaps, it’s meant to aid in copy pasting into a minibuffer prompt, or to assist running a command in the middle of a macro?
What I do want to know is if there is a way to disable this recursivity the way it is with
isearch safe because it's using read-event instead of a blocking prompt? Is there a hook to trigger
abort-recursive-edit when exiting the minibuffer?
- Why do some minibuffer commands upgrade the minibuffer to a target for
other-window, and block running new minibuffer commands, while others, such as
isearch, do not?
- Is there a way to disable this?
- What is this feature's intended use case?