Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie <acm@muc.de>]

Hello again, Martin.

On Tue, Jan 05, 2021 at 19:53:23 +0100, martin rudalics wrote:
>  >> - doesn't get me _always_ into the minibuffer window of the frame
>  >>     switched to (I'm not sure whether it should and under which
>  >>     circumstances - this should be clarified),

>  > I don't think it should, in general, unless the miniwindow is (still) the
>  > frame's current window.

> OK.  Let's stick to this rule.

:-)

>  > I've found out why, in Gregory's scenario, after the "middle" RET to
>  > visit a file, point was not moving back to the "middle frame": it's
>  > because select_frame is insufficient of itself to move X-Window's focus,
>  > which stays in the "old" frame.  Any command now causes a "switch-frame"
>  > event which moves the minibuffers back into the "old" frame, which isn't
>  > what we want.  The solution (a bit ugly) is to call the lisp function
>  > select-frame-set-input-focus rather than just do_switch_frame near the
>  > end of read_minibuf.

> This is indeed ugly and might harm 'redirect-frame-focus'.

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.

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.

>  >> How do I edit an outer level minibuffer whilst an inner level buffer is
>  >> active?

>  > At the moment, you can't.  This isn't good.

> I think it is good (enough).  Do we want spaghetti minibuffers?

I've changed the handling of outer level minibuffers so that they can be
freely edited (but not exited, see below).

>  >  What do you think of the
>  > following solution?

>  > Instead of setting outer minibuffers' maps temporarily to
>  > minibuffer-inactive-mode-map, I could amend exit-minibuffer so that
>  > it would throw an error when there was a more nested active
>  > minibuffer, but leave the current minibuffers untouched.  Also, C-g
>  > should then abort the current minibuffer's caller, together with
>  > those of any more nested MBs.

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

Another possibility, is that rather than a stack of minibuffers, we have
a collection of minibuffers, any one of which (which is accessible) can
be used and exited at any time.  But I can foreseen lots of unforeseen
problems happening with this, and I don't want to try to implement it at
the moment.

>  > The change in the current version of the patch (attached) is that,
>  > as already mentioned, select-frame-set-input-focus is called rather
>  > than just do_select_frame from near the end of read_minibuf.  Also,
>  > that call has been moved from just after the recursive edit to the
>  > very end of read_minibuf.  Also, move_minibuffer_onto_frame now
>  > moves the entire stack of minibuffers, not just the current one (it
>  > is not called when minibuffers-follows-selected-frame is nil).

>  > How would you feel about committing this patch?  It is an improvement
>  > over the current state, even though not yet finished.

> Let's wait for a week at least.  I'd really want to hear the comments
> from the rest of the bunch.

OK.  My feeling at the moment is the patch is now finished (apart from
some documentation changes).  Maybe I should push out another patch,
though I'm not doing that right at the moment.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).