bug#46827: Broken initial size of GTK3 frame

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Cc: stephen.berman@gmx.net, rpluim@gmail.com, 46827@debbugs.gnu.org
> Date: Wed, 3 Mar 2021 09:48:16 +0100
> 
>  > Thanks, but is there any reason to remove the call before updating the
>  > tool bar?  You see, I believe one of the reasons for the need to
>  > clear_garbaged_frames is that call you suggest to remove.  Why not
>  > leave it there, and _add_ one more call after prepare_menu_bars (and
>  > perhaps condition it on the same condition as prepare_menu_bars)?
> 
> We can obviously do that (see attached patch).  But is there any reason
> we cannot run the
> 
>    do_pending_window_change (true);
>    clear_garbaged_frames ();
> 
> _after_ the
> 
>        prepare_menu_bars ();
>        do_pending_window_change (true);
> 
> block?

I have no idea, and don't know how to check that.  We could try, and
then be ready to fix any adverse effects this could cause.

> In either case, the more I look into this, the more things confuse me.
> For example, why does
> 
>         if (!must_finish)
>           {
>             do_pending_window_change (true);
>             /* If selected_window changed, redisplay again.  */
>             if (WINDOWP (selected_window)
>                 && (w = XWINDOW (selected_window)) != sw)
>               goto retry;
> 
> not check for windows_or_buffers_changed too just as we do after the
> third do_pending_window_change call?

Because going to 'retry' will eventually make that check again.  Or
maybe I don't understand what exactly are you asking here?

> But then I don't understand why we
> check for windows_or_buffers_changed at all.  adjust_frame_size doesn't
> set that IIUC but it does garbage the frame - why don't we check that in
> redisplay_internal?

Sorry, I don't understand the question.  We _are_ talking about
redisplay_internal, right? and redisplay_internal does check
windows_or_buffers_changed, right? so what do you mean by "why don't
we check that in redisplay_internal"? and what is "that" in this case?

>  >> While frame resizing can make the
>  >> selected window small, it will neither remove nor change it.
>  >
>  > Never-ever?
> 
> Never-ever.  Fdelete_window_internal, Fdelete_other_windows_internal and
> Fset_window_configuration are the only functions allowed to delete
> windows.

Not even due to some Lisp hook run directly or indirectly when the
frame is resized?

If this can never happen, we should replace the test with an
assertion, and wait for it to fire if we are missing something.

> run_window_change_functions could delete the selected window
> so we probably should do the w == sw check after that now.

Yes, I think so.  Patches welcome.