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: Sean Whitton <spwhitton <at> spwhitton.name>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 76275 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, shipmints <at> gmail.com
Subject: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on recent master
Date: Mon, 17 Feb 2025 09:22:29 +0800

Hello,

On Sat 15 Feb 2025 at 11:34am +01, martin rudalics wrote:

> So the sequence of events is apparently
>
> - You are in an initial phase where 'frame-inhibit-implied-resize'
>   non-nil has no effect because the tool bar was not yet resized.
>
> - You trigger a frame size change via 'set-face-attribute' which
>   apparently "gets through", that is, resizes the frame which is
>   something that should not happen.
>
> - When the tool bar gets finally resized it's too late.  The last
>   change can be no more undone.

This frame has no toolbar, because it's a (minibuffer . only) frame.
Did you notice that?  I don't know whether it's significant.

> Are you sure you did something like
>
>       if (!FRAME_LIVE_P (f)
> 	  || !f->can_set_window_size
> 	  || !f->after_make_frame
> 	  || !f->tool_bar_resized
> 	  || FRAME_TOOLTIP_P (f)
> 	  || !(frame_window_change
> 	       || frame_selected_change
> 	       || frame_selected_window_change
> 	       || frame_window_state_change))
> 	/* Either we are not allowed to run hooks for this frame or no
> 	   window change has been reported for it since the last time
> 	   we ran window change functions on it.  */
> 	continue;
>
> If that hook is still run, we'd have to find out why.

Oops.  I patched run_window_configuration_change_hook, not
run_window_change_functions.  Sorry about that!  So, let me go back to
the debugging instructions in your previous e-mail.

First I tried the unpatched code and printed the three variables.  My
breakpoint was hit eight times and in each case, f->can_set_window_size
and f->after_make_frame were true, and f->tool_bar_resized was false.

Then I patched in the check for f->tool_bar_resized.  This makes the
problem not reproducible.

> I am also stupefied by the fact that the
>
>>      (with-selected-frame frame
>>        (apply #'completing-read prompt collection optional-args))))
>
> is apparently needed.  WOW a pure 'make-frame' together with the hook on
> 'window-size-change-functions' is _not_ sufficient.  Right?

Yes, I just reconfirmed this.

> Is the
>
> (apply #'completing-read prompt collection optional-args))))
>
> needed literally or would just selecting the frame suffice?  Or does
> ‘completing-read’ trigger the window size change that puts the bad
> sequence in motion?

I just tested this.  I replaced

--8<---------------cut here---------------start------------->8---
    (with-selected-frame frame
      (apply #'completing-read prompt collection optional-args))
--8<---------------cut here---------------end--------------->8---

with

--8<---------------cut here---------------start------------->8---
    (select-frame frame)
--8<---------------cut here---------------end--------------->8---

and then, indeed, the problem is not reproducible.  So just selecting
the frame does *not* suffice.

> One other thing: Would enlarging the scope via
>
> (defun spw/scale-default (frame)
>   (let ((frame-inhibit-implied-resize t))
>     (set-face-attribute 'default frame :height 120)))
>
> change anything?

I just tested this.  No, it doesn't help.  The problem is still
reproducible.

> When worse comes to worst, we can always make the offending commit
> optional but I'd rather like to find out what happens first.

Thanks again for your help.

-- 
Sean Whitton

Previous Next

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