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

Previous Next

Full log

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

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

> I believe that what might be unclear in my case is how
> window-size-change-functions is meant to apply to the creation of a new
> frame, rather than the easier case of resizing an existing frame.

'frame-inhibit-implied-resize' was primarily intended for the latter.
We only see now how it can affect the creation of new frames.  We set
the can_set_window_size slot as late as possible during frame creation,
that is we try to delay the impact of 'frame-inhibit-implied-resize' as
long as possible anyway.

But eventually we do have to run into redisplay: IIUC on the one hand
because with some builds we draw menu and tool bars ourselves and want
to have a unified flow of frame creation.  On the other hand, because
elements on these bars depend on the buffer shown in the initial window
and its major mode.

What would be interesting with your setup would be to find out in which
case(s) the return values of frame_inhibit_resize differ when
'frame-inhibit-implied-resize' is t from when it is 'force.  Then we
could explain better how these settings influence initial resizing.

martin

Previous Next

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