bug#48674: Frames and minibuffer bug

[Alan Mackenzie]

Hello, Martin.

On Sat, May 29, 2021 at 17:12:58 +0200, martin rudalics wrote:
>  > When the user switches from F1 to F2 with C-x 5 o, and there was an
>  > active minibuffer on F1, that MB gets moved to F2.  The user then
>  > terminnates the MB....then switches back to F1.  There is no longer an
>  > active MB.

>  >> As a user I can always do

>  >> (select-window (minibuffer-window))

>  >> regardless of whether a minibuffer is active.  Switching away from that
>  >> window's frame and back to it is problematic in Emacs 27 - no window has
>  >> the active cursor.  You apparently fixed this by selecting the frame's
>  >> first window when switching back.  Right?

>  > Yes.

> This is safe but not quite right.  The last window on that frame
> selected before the minibuffer window got selected should be selected
> instead - that's the window returned by `minibuffer-selected-window'
> immediately after selecting the minibuffer window.  We'd probably have
> to put that into the frame structure to make it work but this can wait.

I agree, this can wait.  ;-)

>  >> One reason why I ask is because with emacs -Q and the present patch

>  >> (setq default-frame-alist '((minibuffer . nil)))

>  >> followed by C-x 5 2 and

>  >> (select-window (minibuffer-window))

>  >> in the new frame violates the assertion on line 548 of window.c

>  >>         /* Fselect_frame called us back so we've done all the work 
> already.  */
>  >>         eassert (EQ (window, selected_window));

>  >> with the backtrace below.

>  > Just as a quick aside, how do I configure Emacs so as to generate these
>  > easserts?  At the moment I've got CFLAGS='-O0 -g3' and --enable-checking

> I use

>   --enable-checking='yes,glyphs' --enable-check-lisp-object-type=yes

> but cannot tell which ones are right, which matter and from where I
> obtained them.

Thanks.  It was just me being a bit stupid.  I had
minibuffer-follows-selected-frame set to nil, so I didn't get to the code
which easserts.  On setting that variable to t, I did get it.

[ .... ]

>  > Maybe the best workaround would be to create a new flag in struct frame,
>  > which when set means "select mini-window if "possible" when selecting
>  > this frame".  "Possible" meaning there's an active MB.
>  > (i) This flag would be set, somehow, by with-selected-frame when moving
>  > away from F1.

> I doubt that anyone knows when we move away from a frame.  With

> emacs -Q --eval "(setq default-frame-alist '((minibuffer)))"

> do in the normal, non-minibuffer frame

> (select-window (minibuffer-window))

> You will see that the previous window remains selected but its mode line
> changes to inactive.  So even the display engine doesn't know which
> frame is selected here.  Maybe on purpose ...

I've been thinking about my proposed mechanism.  There is no need for
with-selected-frame to set that new flag in struct frame.  More simply,
do_switch_frame can set it whenever the old frame has the mini-window
selected.  In the new frame it will check the flag and if appropriate
select the MW.  Functions such as Fselect_window and
Fset_frame_selected_window which want to select a specific window would
clear the flag.

This mechanism could be implemented entirely in the C code, without
affecting any Lisp interfaces.

>  > (ii) do_switch_frame would test this flag, act on it, and clear it.
>  > f->flag would always be clear when f is the selected frame.

>  > With this, F1's selected window would be moved away from the mini-window
>  > and the flag set, when F2 gets selected.  Or something like that.

> do_switch_frame is called by (i) and (ii) - so how would you "set" this
> flag in (i) and "test this flag and act on it" in (ii)?  How would
> do_switch_frame distinguish between (i) and (ii)?

Sorry, I think I was a bit unclear.  The flag would be in struct frame,
so (i) and (ii) would be acting on the flags for different frames.

> OTOH what would go wrong if we did always auto-select a minibuffer
> window in do_switch_frame when it is its `frame-selected-window' and
> `minibuffer-depth' is non-zero regardless of whether the window's
> minibuffer is on live_minibuffer_p or not?  If it is not, then this
> frame would just become the next participant in moving the minibuffer
> from one frame to another.

I don't think that situation can arise.  We're talking exclusively about
the (eq minibuffer-follows-selected-frame t) case, and in this case there
will always be a live minibuffer moved onto the target frame when
minibuffer-depth is non-zero.

I think I'm going to discard yesterday's attempted patch, and write
another patch along the lines sketched above.  This will likely take me
longer than just this evening.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).