Subject: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on recent master

From: Eli Zaretskii <[email-masked]>
Date: Thu, 27 Feb 2025 16:40:36 +0200

> Date: Tue, 25 Feb 2025 10:25:40 +0100
> Cc: [email-masked], [email-masked], [email-masked]
> From: martin rudalics <[email-masked]>
> 
>  > How about if, instead of saying what kinds of resizing will NOT
>  > happen, we say what WILL happen?  The resizing seems to have two
>  > stages, so maybe we should describe them, since the 3 settings of this
>  > option seem to control which stage(s) is/are allowed to happen?  What
>  > happens in the stage until "Emacs agrees with the window manager on
>  > the frame size"? what causes the resize in this stage, and what is not
>  > taken into account?  And what is the second stage of the resize?
>  >
>  > Also, the use of "initial size" is confusing, especially when you say
>  > "final initial size".  What is the importance of the "initial" here?
> 
> The initial size of a frame can be specified by ‘initial-frame-alist’,
> 'default-frame-alist' and X resources, among others.  A non-initial
> frame size is one specified by 'set-frame-height', 'set-frame-width' or
> modifying a frame parameter.  'frame-inhibit-implied-resize' t affects
> the non-initial part only.  Conceptually, because nothing hinders people
> from interspersing the latter with the former.
> 
> In the Initial Frame Parameters section we say that
> 
>       If these settings affect the frame geometry and appearance, you’ll
>       see the frame appear with the wrong ones and then change to the
>       specified ones.  If that bothers you, you can specify the same
>       geometry and appearance with X resources; those do take effect
>       before the frame is created.  *Note X Resources: (emacs)X
>       Resources.
> 
> The "final" initial size is the one that can be seen and retrieved after
> the "change to the specified ones".  It can be seen by users who wait
> for an unspecified period of time, but still long enough, until the size
> of the frame has stabilized on screen.  With an initially invisible or
> iconified frame it can be seen only after the frame has been made
> visible for the first time.
> 
> With GTK this moment happens after the tool bar has been updated for the
> first time which is triggered by redisplay and usually happens some time
> after Emacs considers a frame official - that is after is had added the
> frame to 'frame-list' and run 'after-make-frame-functions'.
> 
> So ultimately, for GTK the difference of the values 't' and 'force' for
> 'frame-inhibit-implied-resize' is determined by redisplay_tool_bar in
> xdisp.c and update_frame_tool_bar in gtkutil.c and I have no good idea
> how to explain these moments in the manual.

Maybe we should instead explain which settings could cause resize with
t, but not with 'force'?