bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#48674: Frames and minibuffer bug


From: Alan Mackenzie
Subject: bug#48674: Frames and minibuffer bug
Date: Sat, 29 May 2021 13:10:09 +0000

Hello, Martin.

On Sat, May 29, 2021 at 11:20:58 +0200, martin rudalics wrote:
>  > I think the following patch, along the above lines, solves the bug
>  > completely.  Could you review it for me, please?

Thanks for the review.  I withdraw my assertion about a complete
solution to the bug.  :-(

> It fixes the bug and the potential use case I mentioned earlier.  But
> for this part

>    /* If the new frame's selected window is the mini-window, select
>       some other window if we don't have an active minibuffer there.  */
>    if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (f)))
>        && !live_minibuffer_p (XWINDOW (FRAME_SELECTED_WINDOW (f))->contents))
>      Fselect_window (Fframe_first_window (selected_frame), Qnil);

> I would first have to understand why such a minibuffer window should be
> OT1H its frame's selected window and OTOH not be active when switching
> back to that frame.

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.

> 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
in my ./configure command line.  I think I'm missing something.

> Basically, I would try to avoid that a non-selected frame's selected
> window is an inactive minibuffer window.  But I'm not sure how difficult
> it is to achieve that.

That's the way it currently is (without the patch).  It is difficult to
make it work properly.

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

What do you think?

> martin

[ Backtrace snipped, but understood. ]

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]