When focus follows the mouse, it is difficult to avoid selecting it
if it shows up under the mouse.
I didn't have focus-follows-mouse turned on.
If it were on, and if the new frame did not happen to show
up under the mouse, it would not be selected, right?
No, that variable is meant to tell Emacs what the window manager does.
My bad. So users must set it, to tell Emacs about the window manager. But
couldn't the default value be defined reasonably for a few common window
managers?
In emacs -q on Windows, its value is t, but Windows requires you to click a
frame to set the focus. Shouldn't the default value be nil on Windows?
Especially since there is only one window-manager for Windows, so it is easy
to test it - just test the OS.
Anyway, this is all unrelated to the problem at hand.
I guess you're saying that when a frame is created it is
always given the focus. That's too bad.
I am saying that the system decides what frame gets focus.
But what about Stefan's patch? It sounded like it might take care of this
annoyance.
The problem arises because one frame's minibuffer is expecting input, while
another frame (*Completions*) gets created and selected (depending on the
window manager). The input dialog gets totally lost (interrupted),
systematically. This is a problem of frame focus. Leaving it the way it is
discourages people from using pop-up-frames = t, because this behavior is so
annoying.
As I said:
I don't have this problem, because I have dedicated
frames for *Customize* and the minibuffer, and I use a
special-display function to display *Customize*.
That function explicitly redirects the focus from the
*Customize* frame back to the minibuffer frame.
Couldn't something equivalent be done, in a more basic way, to ensure that
the input focus for *Completions* remains the original minibuffer that
launched it? The way things are now, it's like opening a door and having it
slam shut in your face.
IOW, independently of the window manager and OS behavior, shouldn't the
input focus for *Completions* be the minibuffer that displayed it?
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
