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

From: martin rudalics <[email-masked]>
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