Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

> Actualy, I don't think it's as ugly as all that.
> select-frame-set-input-focus is an extremely coherent function; it does
> one thing and does it well, i.e. switch frames.  Maybe it's a pity that
> it's a Lisp function rather than a C function, but it is as it is.

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'.

> I've been trying to think through the bit about redirect-frame-focus.
> It's difficult.  Are you aware of any particular scenarios where it might
> go wrong with select-frame-set-input-focus?  Or is it more a general
> concern, possibly from past experience?  For example if the source frame
> has focus redirected to a MB-only frame, and s-f-s-i-focus is called,
> should that redirected focus be undone?  I'm a little confused about the
> difference between a MB-only frame being the selected frame, and it being
> the focus frame of a different "normal" frame.

I already had to revert one change because I got that wrong.  It's again
mostly about using 'focus-follows-mouse' t with a standalone minibuffer
frame and I've never been able to understand how people manage that when
the normal frame practically completely covers the minibuffer frame.
But sooner or later this point will get moot because with Wayland people
will be no more able to put a standalone minibuffer frame wherever they
want to.

>> We're right in hell's kitchen here.
>
> I've actually implemented the above, on a trial basis.  It was actually
> surprisingly easy.  The C-g bit was just 9 extra lines (plus comments) in
> internal_catch (eval.c), and another small function in minibuf.c.
>
> You say "hell's kitchen".  Again, is this on general principles,

Just gut feeling.

> or can
> you see some specific problems which might crop up?  My feeling is that
> this way of dealing with "not the innermost minibuffer" is simple, and
> possibly as good as we're going to get.

martin