[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed removal of struct frame->select_mini_window_flag.
From: |
Eli Zaretskii |
Subject: |
Re: Proposed removal of struct frame->select_mini_window_flag. |
Date: |
Wed, 18 May 2022 20:16:24 +0300 |
> Date: Wed, 18 May 2022 17:03:13 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
>
> > sf->select_mini_window_flag = MINI_WINDOW_P (XWINDOW
> > (sf->selected_window));
>
> > selected_frame = frame;
>
> > move_minibuffers_onto_frame (sf, for_deletion);
>
> > if (f->select_mini_window_flag
> > && !NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents,
> > Qt)))
> > f->selected_window = f->minibuffer_window;
>
> Yes, I saw it.
>
> > How will this logic work without that flag?
>
> There is no logic which uses it.
How do you mean "no logic"? I mean this logic, right there:
if (f->select_mini_window_flag
&& !NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt)))
f->selected_window = f->minibuffer_window;
> These lines in frame.c set the flag in
> sf (the old frame), and test it in f (the new frame). It is intended to
> be a durable flag saying whether or not the mini-window in a non-selected
> frame is to be selected at the next do_switch_frame () into it. This
> might make sense if there were something setting f->selected_window without
> going through the proper functions.
The code above does just that, does it not? It directly sets
f->selected_window.
> What we do have is the setting of the flag unconditionally to false in
> select_window (window.c), with no attempt being made to save and restore
> the current value. Considering that Fselect_window can be called from
> gui_consider_frame_title (xdisp.c) during a redisplay (with the current
> bug fix), this means the flag can be initialised to false asynchronously
> at any time.
What do you mean by "asynchronously"? gui_consider_frame_title is not
called asynchronously, at least under my interpretation of that term.