GNU bug report logs - #76275
31.0.50; frame-inhibit-implied-resize broken on recent master

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 76275 <at> debbugs.gnu.org, shipmints <at> gmail.com, spwhitton <at> spwhitton.name
Subject: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on recent master
Date: Mon, 24 Feb 2025 21:42:22 +0200

> Date: Mon, 24 Feb 2025 09:52:53 +0100
> Cc: spwhitton <at> spwhitton.name, 76275 <at> debbugs.gnu.org, shipmints <at> gmail.com
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > 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?

Previous Next

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