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

From: Eli Zaretskii <[email-masked]>
Date: Mon, 24 Feb 2025 21:42:22 +0200

> Date: Mon, 24 Feb 2025 09:52:53 +0100
> Cc: [email-masked], [email-masked], [email-masked]
> From: martin rudalics <[email-masked]>
> 
>  > Thanks, but could you please clarify the difference between the values
>  > t and 'force' of frame-inhibit-implied-resize?  I'm confused by "no
>  > resizing once a frame has obtained its initial size" vs "no implicit
>  > resizing whenever a new frame is made".  This seems to imply that
>  > there are several stages in the resizing, but they are not explicitly
>  > described.
> 
> I've tried to be more verbose in the manual and the doc-string now.
> Please have a look.

Thanks.  It's better, but I think we still need to improve it.

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?