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: Thu, 27 Feb 2025 16:40:36 +0200

> Date: Tue, 25 Feb 2025 10:25:40 +0100
> Cc: spwhitton <at> spwhitton.name, 76275 <at> debbugs.gnu.org, shipmints <at> gmail.com
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > 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'?

Previous Next

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