moving the mark back into the main buffer leaves things in a goofy state

[cburroughs]

TEMP="$(mktemp -d | tee /dev/stderr)"

cat >"$TEMP/.emacs" <<EOF
(setq custom-file "/dev/null")

(package-initialize)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))

(package-install 'ctrlf)
EOF

HOME="$TEMP" emacs

1. M-x ctrlf-mode
2. C-s emacs
3. click with the mouse anywhere in the buffer

Things are now in a --- for lack of a more technical term --- goofy state. You can move around, type words etc, but all of the ctrlf faces are still applied and typing M-x gives the "use minibuffer while in minibuffer" error. Typing C-s again seems to get things back into a reasonable state.

NOTE: I keep falling into this case without using the mouse, but I'm not sure how. This is a small reproduction case for what I hope is the same issue (or at least a similar one).

[raxod502]

This actually happens with all Emacs functions that read from the minibuffer. You can reproduce easily without the mouse by typing C-x o to switch out of the minibuffer. Generally, in Emacs, you're expected to cancel out of the minibuffer using C-g or another binding, rather than switching to another buffer. This is because you may in some circumstances actually want to visit another buffer without closing the minibuffer (e.g. to copy and paste some text from it).

I personally have this code in my personal Emacs configuration to make the behavior more ergonomic; that is, typing C-g in any buffer will exit the minibuffer if it is open.

So, nominally not a bug, although I am open to suggestions on how we could make CTRLF's behavior less surprising without breaking other things.

[cburroughs]

Well, still more new things to learn about emacs a decade later! I assume some of isearch's 'easy to accidentally stop editing the search' quicks also avoid this.

I'll try to figure out what combination of keyboard commands causes me to keep tripping over this. Maybe there is something more specific that can be done there.

[raxod502]

Yeah, most keys are unbound in isearch, or rebound to special things, so it's hard to exit the minibuffer without aborting isearch, which I suppose you can consider to be a feature. With CTRLF you have the default minibuffer bindings, which unfortunately/fortunately (depending on your point of view) makes it much easier to escape.

[raxod502]

This thread is being closed automatically by Tidier because it is labeled with "waiting on response" and has not seen any activity for 90 days. But don't worry—if you have any information that might advance the discussion, leave a comment and I will be happy to reopen the thread :)

[radrow]

To me that's actually pretty annoying. I ditched isearch specifically because of this, since it was barely usable with a similar issue. It just takes a single mouse click to enter this fragile state, which is especially irritating if I move around my project, switch windows a couple of times, and then it turns out that

• I can't search
• In order to fix it, I have to click with my mouse onto the minibuffer, as no keybind lets me focus it for whatever reason
• When I quit the minibuffer, some random window just switches to the buffer in which the search was initiated and jumps to the cached location

The builtin search somehow does not have those issues. It just knows when to close and, most importantly, does not cause that violent jumping around open buffers.

[raxod502]

I have this problem too, still. Can reopen to track making the behavior more reasonable.