Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie <acm@muc.de>]

Hello, Martin.

On Sun, Jan 10, 2021 at 17:04:57 +0100, martin rudalics wrote:
>  >> It does call 'raise-frame' something people with 'focus-follows-mouse' t
>  >> (not 'auto-raise') might not want here.  And it may have to move the
>  >> mouse cursor according to the 'mouse-autoselect-window' and
>  >> 'focus-follows-mouse' policies.  Most window managers don't handle the
>  >> latter well (IIRC only the otherwise abominable mutter and KDE could do
>  >> it approximately).  And the former wants the selected window to be set
>  >> up well before calling 'select-frame-set-input-focus'.

>  > It is nevertheless the standard function to call to move focus to a
>  > different frame.  If there are problems with focus-follows-mouse, they
>  > should surely be fixed in frame.el as a separate problem.

> The 'focus-follows-mouse' problem is a window manager problem and cannot
> be fixed in frame.el.  It typically happens when he mouse pointer is (i)
> over frame-1, one (ii) gives focus to frame-2 and (iii) moves the mouse
> which causes the WM to refocus frame-1.  Some WMs here move the mouse
> pointer in (ii) to frame-2 (and forcefully do that for pop up windows)
> which can be however a pain for Emacs because the WM doesn't know where
> in frame-2 to move it to and so with 'mouse-autoselect-window' a wrong
> window may get auto-selected.

> And please remain aware of the fact that focus stealing is, in general,
> considered bad practice.  It shouldn't happen in the case at hand
> because _some_ Emacs frame should already have focus when invoking
> 'select-frame-set-input-focus'.  Still, a window manager's local policy
> settings might make it refrain from giving focus to some frame on behalf
> of our request.

The need to set the focus is as follows.  Suppose we replace the
select-frame-set-input-focus with the select-frame (actually,
do_switch_frame) that was previously there.

With minibuffer-follows-selected-frame t (the default),
enable-recursive-minibuffers t:

Three frames F1, F2, F3:

On F1, C-x C-f foo.el.  Move to F2: C-x C-f bar.el.  Move to F3 C-x C-f
baz.el RET.

baz.el is visited in F3.  The minibuffers remain in F3.  Move point to
 *Minibuf-2* in F3, and type RET.  bar.el is visited in F2, BUT THE
FOCUS REMAINS IN F3.  This is suboptimal.  If we visit a file in a
frame, the focus should be on that frame, not somewhere else.  As an
analogy, C-x 5 f foo.el visits foo.el on another (typically new) frame
and MOVES THE FOCUS TO THAT FRAME.  Why shouldn't that be done in the
current scenario?

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).