GNU bug report logs - #46827
Broken initial size of GTK3 frame

Previous Next

Full log

Message #95 received at 46827 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46827 <at> debbugs.gnu.org, rpluim <at> gmail.com, stephen.berman <at> gmx.net
Subject: Re: bug#46827: Broken initial size of GTK3 frame
Date: Wed, 3 Mar 2021 10:40:04 +0100

>> 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?

The check above doesn't care about windows_or_buffers_changed.  The last
one in redisplay_internal does:

  /* Change frame size now if a change is pending.  */
  do_pending_window_change (true);

  /* If we just did a pending size change, or have additional
     visible frames, or selected_window changed, redisplay again.  */
  if ((windows_or_buffers_changed && !pending)
      || (WINDOWP (selected_window)
	  && (w = XWINDOW (selected_window)) != sw))
    goto retry;

So if in the (!must_finish) guarded check windows_or_buffers_changed was
set but the selected window remained unchanged, we don't go to retry.

>> 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?

I meant to ask why we don't check the f->garbaged flag of the frame
instead of windows_or_buffers_changed.  do_pending_window_change to my
knowledge does not set windows_or_buffers_changed but sets the garbaged
flag.

>> 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?

run_window_scroll_functions could do it later on, but that is run by
redisplay itself.

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

I'll try that here.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.