Since upgrading from v. 24 to v. 25 [OSX 10.11.6] I find myself frequently fighting with minibuffer completion, as typing a tab after doing switch-to-buffer. ^G just beeps, and the completions redisplay. The only way I know to exit the minibuffer in this situation is to pick one of the completions, either with the mouse or by navigating with keys. I have a pretty simple setup with respect to switch-buffer. I don't think I use any buffer libraries that would affect his, and have not changed buffer handling for several versions. Any suggestions about what is causing this and how I can get out of minibuffer completion without choosing one of the completions?
Is it possible there is an active recursive edit in the completion minibuffer? C-] by default is
keyboard-escape-quit or ESC ESC ESC might help?
I was seeing the same thing, but I knew that for me it had started sometime after I'd upgraded to and had been using Emacs 25. In my case, the problem turned out to be my recent addition of the following to my
(set-frame-parameter nil 'unsplittable t)
The above was one of several things I had used to try to undo some other behavior changes that Emacs 25 brought in. In this case, it wasn't the right thing to try.
This also might explain why I didn't seem to get stuck in the minibuffer when I was running with my full
~/.emacs configuration, yet in
--no-window-system (-nw) mode. There, as I understand it, frames aren't even a thing.
Aha! This has been making me crazy for a long time. Today I spent some more time searching and exploring. I stumbled on the answer after doing ^H-m when in the minibuffer. The fourth keybinding listed is "q", quit-window. Typing q when completions are displayed closes the completion buffer and returns to the minibuffer, where ^G aborts normally.
I don't understand why it was so difficult for me to figure this out, or why there aren't a lot of people complaining about this.