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

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76275 <at> debbugs.gnu.org, shipmints <at> gmail.com, spwhitton <at> spwhitton.name
Subject: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on recent
 master
Date: Tue, 25 Feb 2025 10:25:40 +0100

> 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.  In either case, the last
two bug reports in this area were both triggered by this discrepancy so
I agree that further clarification might be needed.

martin

Previous Next

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