6

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 other-window.
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 other-window + keyboard-quit.

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. Is 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?

TL;DR

  1. 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?
  2. Is there a way to disable this?
  3. What is this feature's intended use case?
Malabarba
  • 22,878
  • 6
  • 78
  • 163
dgtized
  • 4,169
  • 20
  • 41
  • 2
    Your question is unclear, to me. Just what are you trying to do? `C-]` aborts one level of minibuffer, yes. Isearch does not use the minibuffer. And what does "**stuck in prompt**" have to do with any of the rest of what you describe? You should not need to use `switch-window` at all, in such contexts. But it is not clear what you are trying to do. Try to separate the various pieces of your description, and try to come up with a single question. – Drew Oct 08 '14 at 00:01
  • 2
    Try setting `enable-recursive-minibuffers` to `t` to avoid the *Command attempted to use minibuffer while in minibuffer* message. It might help clarify the original question, if you posted the question on `recursive-edit` separately. – Vamsi Oct 08 '14 at 00:59

3 Answers3

5
  1. Many interactive commands read minibuffer input. find-file is one such command. Reading minibuffer input "activates" the minibuffer window, which is why you can switch to it with the other-window command. Interactive isearch is special because it's implemented as a minor mode. It doesn't technically read your search string from the minibuffer, but instead catches your keypresses as you type and echoes them to the minibuffer with message. This is why you see other-window behaving differently.
  2. This may or may not help you, but technically you can modify the prompt behavior of find-file by modifying the function stored in read-file-name-function. I haven't tried advising the function based on @kaushalmodi's answer, but if that works I'll update this.
  3. I can't speak for any of the hackers who worked on the code in minibuffer.el, but from the following description in the manual I'd guess the behavior is designed to let you kill-and-yank text:

When the minibuffer is active, the echo area is treated much like an ordinary Emacs window. For instance, you can switch to another window (with C-x o), edit text there, then return to the minibuffer window to finish the argument. You can even kill text in another window, return to the minibuffer window, and yank the text into the argument.

purple_arrows
  • 2,373
  • 10
  • 19
2

The below snippet [Source] aborts recursive edit when focus moves away from the minibuffer. This is to avoid the irritating occassions where repeated C-g pressing doesn't edit the mini-buffer as cursor focus has moved out of it.

(defun stop-using-minibuffer ()
  "kill the minibuffer"
  (when (and (>= (recursion-depth) 1) (active-minibuffer-window))
    (abort-recursive-edit)))
(add-hook 'mouse-leave-buffer-hook 'stop-using-minibuffer)
Community
  • 1
Kaushal Modi
  • 25,203
  • 3
  • 74
  • 179
1

Drew has already commented on this, but...

isearch1 doesn't actually use the minibuffer, which probably accounts for part of your confusion. It displays things in the echo area (which is in the same window as the minibuffer, but isn't actually the minibuffer).

That being the case, the notion of switching to and from the minibuffer while running an isearch doesn't make any sense.

1 Ignoring commands like isearch-edit-string which do use the minibuffer, but aren't part of the most basic isearch workflow.

phils
  • 48,657
  • 3
  • 76
  • 115