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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76275 in the body.
You can then email your comments to 76275 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; frame-inhibit-implied-resize broken on recent master
Date: Fri, 14 Feb 2025 11:28:10 +0800

X-debbugs-cc: rudalics <at> gmx.at, shipmints <at> gmail.com

Hello,

By means of Git bisection I have discovered that commit dbf22fd0d05 to
fix bug#74750 has broken frame-inhibit-implied-resize.
Here is a reproducer:

1. Configure the Sway compositor to move and resize new windows that
   open if they have the title "Emacs Sway input":
--8<---------------cut here---------------start------------->8---
for_window [title="^Emacs Sway input$"] \
	floating enable, sticky enable, \
	resize set width 90 ppt, resize set height 90 px, \
	border pixel 2, move position 5 ppt 10 px
--8<---------------cut here---------------end--------------->8---

2. Create sway-completing-read.el:
--8<---------------cut here---------------start------------->8---
(defun spw/scale-default (frame)
  (set-face-attribute 'default frame :height 120))
(add-to-list 'window-size-change-functions #'spw/scale-default)

(defun spw/sway-completing-read (prompt collection &rest optional-args)
  (let* ((frame-inhibit-implied-resize t)
	 (frame (make-frame `((title . "Emacs Sway input")
			      (minibuffer . only)
			      (display . ,(getenv "WAYLAND_DISPLAY"))))))
    (unwind-protect
	(with-selected-frame frame
	  (set-window-scroll-bars (minibuffer-window frame) 0 nil 0 nil t)
	  (apply #'completing-read prompt collection optional-args))
      (delete-frame frame))))
--8<---------------cut here---------------end--------------->8---

3. src/emacs -Q -l sway-completing-read.el --fg-daemon=test

4. lib-src/emacsclient -stest -e '(spw/sway-completing-read "Choose: " (list "one" "two" "three"))'

Result before dbf22fd0d05: New graphical frame of size 90%x90px appears.
Result after dbf22fd0d05: New graphical frame of a different size appears.

I think what happens is that Sway moves and resizes the new frame, but
then Emacs immediately wants to resize it after scaling the font size.
Binding frame-inhibit-implied-resize used to prevent that, but it's now
broken.

Thanks.

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 76275 <at> debbugs.gnu.org, rudalics <at> gmx.at, shipmints <at> gmail.com
Subject: Re: bug#76275: 31.0.50;
 frame-inhibit-implied-resize broken on recent master
Date: Fri, 14 Feb 2025 10:24:17 +0200

> Cc: rudalics <at> gmx.at, shipmints <at> gmail.com
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Fri, 14 Feb 2025 11:28:10 +0800
> 
> By means of Git bisection I have discovered that commit dbf22fd0d05 to
> fix bug#74750 has broken frame-inhibit-implied-resize.
> Here is a reproducer:
> 
> 1. Configure the Sway compositor to move and resize new windows that
>    open if they have the title "Emacs Sway input":
> --8<---------------cut here---------------start------------->8---
> for_window [title="^Emacs Sway input$"] \
> 	floating enable, sticky enable, \
> 	resize set width 90 ppt, resize set height 90 px, \
> 	border pixel 2, move position 5 ppt 10 px
> --8<---------------cut here---------------end--------------->8---
> 
> 2. Create sway-completing-read.el:
> --8<---------------cut here---------------start------------->8---
> (defun spw/scale-default (frame)
>   (set-face-attribute 'default frame :height 120))
> (add-to-list 'window-size-change-functions #'spw/scale-default)
> 
> (defun spw/sway-completing-read (prompt collection &rest optional-args)
>   (let* ((frame-inhibit-implied-resize t)
> 	 (frame (make-frame `((title . "Emacs Sway input")
> 			      (minibuffer . only)
> 			      (display . ,(getenv "WAYLAND_DISPLAY"))))))
>     (unwind-protect
> 	(with-selected-frame frame
> 	  (set-window-scroll-bars (minibuffer-window frame) 0 nil 0 nil t)
> 	  (apply #'completing-read prompt collection optional-args))
>       (delete-frame frame))))
> --8<---------------cut here---------------end--------------->8---
> 
> 3. src/emacs -Q -l sway-completing-read.el --fg-daemon=test
> 
> 4. lib-src/emacsclient -stest -e '(spw/sway-completing-read "Choose: " (list "one" "two" "three"))'
> 
> Result before dbf22fd0d05: New graphical frame of size 90%x90px appears.
> Result after dbf22fd0d05: New graphical frame of a different size appears.
> 
> I think what happens is that Sway moves and resizes the new frame, but
> then Emacs immediately wants to resize it after scaling the font size.
> Binding frame-inhibit-implied-resize used to prevent that, but it's now
> broken.

Isn't there a race condition here between the resize done by Sway and
by Emacs?  If so, I think the previous result was just due to sheer
luck, as it was exploiting undefined behavior.

Apologies if this makes no sense, but I always wonder why people
expect something deterministic to happen when there are so many moving
parts (in this case: client-to-server communications, the
window-system management of frames, and the precise timing with which
Emacs calls window-size-change-functions).

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

From: martin rudalics <rudalics <at> gmx.at>
To: Sean Whitton <spwhitton <at> spwhitton.name>, 76275 <at> debbugs.gnu.org
Cc: shipmints <at> gmail.com
Subject: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on recent
 master
Date: Fri, 14 Feb 2025 11:25:04 +0100

> By means of Git bisection I have discovered that commit dbf22fd0d05 to
> fix bug#74750 has broken frame-inhibit-implied-resize.
> Here is a reproducer:
>
> 1. Configure the Sway compositor to move and resize new windows that
>     open if they have the title "Emacs Sway input":
> --8<---------------cut here---------------start------------->8---
> for_window [title="^Emacs Sway input$"] \
> 	floating enable, sticky enable, \
> 	resize set width 90 ppt, resize set height 90 px, \
> 	border pixel 2, move position 5 ppt 10 px
> --8<---------------cut here---------------end--------------->8---
>
> 2. Create sway-completing-read.el:
> --8<---------------cut here---------------start------------->8---
> (defun spw/scale-default (frame)
>    (set-face-attribute 'default frame :height 120))
> (add-to-list 'window-size-change-functions #'spw/scale-default)
>
> (defun spw/sway-completing-read (prompt collection &rest optional-args)
>    (let* ((frame-inhibit-implied-resize t)
> 	 (frame (make-frame `((title . "Emacs Sway input")
> 			      (minibuffer . only)
> 			      (display . ,(getenv "WAYLAND_DISPLAY"))))))
>      (unwind-protect
> 	(with-selected-frame frame
> 	  (set-window-scroll-bars (minibuffer-window frame) 0 nil 0 nil t)
> 	  (apply #'completing-read prompt collection optional-args))
>        (delete-frame frame))))
> --8<---------------cut here---------------end--------------->8---
>
> 3. src/emacs -Q -l sway-completing-read.el --fg-daemon=test
>
> 4. lib-src/emacsclient -stest -e '(spw/sway-completing-read "Choose: " (list "one" "two" "three"))'
>
> Result before dbf22fd0d05: New graphical frame of size 90%x90px appears.
> Result after dbf22fd0d05: New graphical frame of a different size appears.
>
> I think what happens is that Sway moves and resizes the new frame, but
> then Emacs immediately wants to resize it after scaling the font size.
> Binding frame-inhibit-implied-resize used to prevent that, but it's now
> broken.

Two (maybe silly) questions:

(1) Is the

> (defun spw/scale-default (frame)
>    (set-face-attribute 'default frame :height 120))
> (add-to-list 'window-size-change-functions #'spw/scale-default)

needed to reproduce the problem and how or why?  If so, then please tell
us (via GDB) when and how these bypass the

	  || !f->can_set_window_size
	  || !f->after_make_frame

check in run_window_change_functions in window.c.  If they do bypass it,
could you insert an additional

          || !f->tool_bar_resized

there and tell us what happens then?

(2) Is the

>      (unwind-protect
> 	(with-selected-frame frame
> 	  (set-window-scroll-bars (minibuffer-window frame) 0 nil 0 nil t)
> 	  (apply #'completing-read prompt collection optional-args))
>        (delete-frame frame))))

needed to reproduce the problem and how or why?

Thanks, martin

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76275 <at> debbugs.gnu.org, rudalics <at> gmx.at, shipmints <at> gmail.com
Subject: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on
 recent master
Date: Sat, 15 Feb 2025 09:00:18 +0800

Hello,

On Fri 14 Feb 2025 at 10:24am +02, Eli Zaretskii wrote:

> Isn't there a race condition here between the resize done by Sway and
> by Emacs?  If so, I think the previous result was just due to sheer
> luck, as it was exploiting undefined behavior.
>
> Apologies if this makes no sense, but I always wonder why people
> expect something deterministic to happen when there are so many moving
> parts (in this case: client-to-server communications, the
> window-system management of frames, and the precise timing with which
> Emacs calls window-size-change-functions).

I agree with you in the general case.  I think my basic approach here
may be flawed and I should try to rewrite it.

Regardless of that, though, it would seem that there is a bug with
frame-inhibit-implied-resize uncovered by this approach of mine, a bug
worth fixing anyway.

-- 
Sean Whitton

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

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: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on
 recent master
Date: Sat, 15 Feb 2025 09:43:43 +0800

Hello,

On Fri 14 Feb 2025 at 11:25am +01, martin rudalics wrote:

> Two (maybe silly) questions:
>
> (1) Is the
>
>> (defun spw/scale-default (frame)
>>    (set-face-attribute 'default frame :height 120))
>> (add-to-list 'window-size-change-functions #'spw/scale-default)
>
> needed to reproduce the problem and how or why?

Yes, it's needed.  I obtained it by bisecting my init.el to find a
minimal reproducer, so I don't know exactly why it's needed.  But I
think it's because changing the face size triggers the kind of implied
resize that frame-inhibit-implied-resize is meant to prevent.

> If so, then please tell us (via GDB) when and how these bypass the
>
> 	  || !f->can_set_window_size
> 	  || !f->after_make_frame
>
> check in run_window_change_functions in window.c.

My breakpoint was hit three times.  In each case, both
f->can_set_window_size and f->after_make_frame were true.

The backtrace in all three cases is the same, in that the code is called
via redisplay.

> If they do bypass it, could you insert an additional
>
>           || !f->tool_bar_resized
>
> there and tell us what happens then?

Each of the three times my breakpoint is hit, f->tool_bar_resized is
false.

I have also observed something else from this debugging.  Switching
focus between GUD (in my main Emacs session) and the incorrectly sized
frame can cause the incorrectly sized frame to jump back to the correct
size.  When that occurs, my breakpoint is not hit.

> (2) Is the
>
>>      (unwind-protect
>> 	(with-selected-frame frame
>> 	  (set-window-scroll-bars (minibuffer-window frame) 0 nil 0 nil t)
>> 	  (apply #'completing-read prompt collection optional-args))
>>        (delete-frame frame))))
>
> needed to reproduce the problem and how or why?

It's needed in some form, yes, but you prompted me to investigate
further and this is my new minimal reproducer:

sway-completing-read.el:
--8<---------------cut here---------------start------------->8---
(defun spw/scale-default (frame)
  (set-face-attribute 'default frame :height 120))
(add-to-list 'window-size-change-functions #'spw/scale-default)

(defun spw/sway-completing-read (prompt collection &rest optional-args)
  (let* ((frame-inhibit-implied-resize t)
	 (frame (make-frame `((title . "Emacs Sway input")
			      (minibuffer . only)
			      (display . ,(getenv "WAYLAND_DISPLAY"))))))
    (with-selected-frame frame
      (apply #'completing-read prompt collection optional-args))))
--8<---------------cut here---------------end--------------->8---

So, the call to set-window-scroll-bars is not essential, but putting
some text in the frame would seem to be essential.

Many thanks for looking!

-- 
Sean Whitton

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

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: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on
 recent master
Date: Sat, 15 Feb 2025 09:47:22 +0800

Hello,

On Sat 15 Feb 2025 at 09:43am +08, Sean Whitton wrote:

> Each of the three times my breakpoint is hit, f->tool_bar_resized is
> false.

Oh, and: inserting this line does not fix the bug.

-- 
Sean Whitton

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

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

>> (1) Is the
>>
>>> (defun spw/scale-default (frame)
>>>     (set-face-attribute 'default frame :height 120))
>>> (add-to-list 'window-size-change-functions #'spw/scale-default)
>>
>> needed to reproduce the problem and how or why?
>
> Yes, it's needed.  I obtained it by bisecting my init.el to find a
> minimal reproducer, so I don't know exactly why it's needed.  But I
> think it's because changing the face size triggers the kind of implied
> resize that frame-inhibit-implied-resize is meant to prevent.

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.

>> If so, then please tell us (via GDB) when and how these bypass the
>>
>> 	  || !f->can_set_window_size
>> 	  || !f->after_make_frame
>>
>> check in run_window_change_functions in window.c.
>
> My breakpoint was hit three times.  In each case, both
> f->can_set_window_size and f->after_make_frame were true.
>
> The backtrace in all three cases is the same, in that the code is called
> via redisplay.
>
>> If they do bypass it, could you insert an additional
>>
>>            || !f->tool_bar_resized
>>
>> there and tell us what happens then?
>
> Each of the three times my breakpoint is hit, f->tool_bar_resized is
> false.

This and your later ....

> Oh, and: inserting this line does not fix the bug.

... are somewhat contradictory.  It means that we should be able to
restore the old behavior with the disjunct added because then we are not
allowed to run the hook.  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.

> I have also observed something else from this debugging.  Switching
> focus between GUD (in my main Emacs session) and the incorrectly sized
> frame can cause the incorrectly sized frame to jump back to the correct
> size.  When that occurs, my breakpoint is not hit.

Since you are apparently running the hook anyway, we could try to do the
debugging within a function run by the hook.  We can also try using
'frame--size-history' to find out who is responsible.  In either case we
have to find out what allows 'set-face-attribute' to run so early.

To clarify: It's one thing that inhibiting implied resizing is not done
in your scenario because 'frame_inhibit_resize' insists on the tool bar
being fully drawn.  The one thing that I want to find out first why in
the case at hand the hook is run although the tool bar has not been
fully drawn yet.

>> (2) Is the
>>
>>>       (unwind-protect
>>> 	(with-selected-frame frame
>>> 	  (set-window-scroll-bars (minibuffer-window frame) 0 nil 0 nil t)
>>> 	  (apply #'completing-read prompt collection optional-args))
>>>         (delete-frame frame))))
>>
>> needed to reproduce the problem and how or why?
>
> It's needed in some form, yes, but you prompted me to investigate
> further and this is my new minimal reproducer:
>
> sway-completing-read.el:
> --8<---------------cut here---------------start------------->8---
> (defun spw/scale-default (frame)
>    (set-face-attribute 'default frame :height 120))
> (add-to-list 'window-size-change-functions #'spw/scale-default)
>
> (defun spw/sway-completing-read (prompt collection &rest optional-args)
>    (let* ((frame-inhibit-implied-resize t)
> 	 (frame (make-frame `((title . "Emacs Sway input")
> 			      (minibuffer . only)
> 			      (display . ,(getenv "WAYLAND_DISPLAY"))))))
>      (with-selected-frame frame
>        (apply #'completing-read prompt collection optional-args))))
> --8<---------------cut here---------------end--------------->8---
>
> So, the call to set-window-scroll-bars is not essential, but putting
> some text in the frame would seem to be essential.

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?  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?

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?

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

martin

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

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: Re: 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

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

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

[Message part 1 (text/plain, inline)]

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

Hopefully not.  The tool_bar_resized flag should be set regardless of
whether a tool bar was made or not.  This is emphasized by this comment
in xdisp.c:

      /* Even if we do not display a tool bar initially, still pretend
	 that we have resized it already.  This avoids that a later
	 activation of the tool bar resizes the frame, despite of the
	 fact that a setting of 'frame-inhibit-implied-resize' should
	 inhibit it (Bug#52986).  */
      f->tool_bar_resized = true;

>> 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.

Should teach me to always include a diff when proposing changes.

> 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.

Sounds encouraging.

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

OK.  So to fix your problem the attached patch suffices?  I also patched
the corresponding part for running the configuration change hook.

>> 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.

Whatever it does, it triggers the hook.

>> 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.

It probably would suffice to show another buffer in that window.

>> 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.

So likely the let-binding in 'make-frame' extends until here.  Can you
confirm that in your "My breakpoint was hit eight times and in each
case, ..." the value of the _variable_ frame_inhibit_implied_resize was
always t while the function with the same name returned false?

martin

[frame-tool-bar-resized.diff (text/x-patch, attachment)]

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

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: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on
 recent master
Date: Mon, 17 Feb 2025 20:07:41 +0800

Hello,

On Mon 17 Feb 2025 at 10:21am +01, martin rudalics wrote:

> OK.  So to fix your problem the attached patch suffices?

I tested this with my actual use case, not just the minimal example.

It does fix the resizing problem.  However, now my entry in
window-size-change-functions doesn't run at all, and so the font size in
the new frame is wrong.

I'm not sure whether this is a bug, but it might count as a change that
should be called out in NEWS?  window-size-change-functions is no longer
guaranteed to be called when frames are simply created.

> So likely the let-binding in 'make-frame' extends until here.  Can you
> confirm that in your "My breakpoint was hit eight times and in each
> case, ..." the value of the _variable_ frame_inhibit_implied_resize was
> always t while the function with the same name returned false?

The variable is always t, indeed.

I'm not sure what you mean "while the function with the same name
returned false" -- there isn't a function called
frame_inhibit_implied_resize, I think?

-- 
Sean Whitton

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

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

[Message part 1 (text/plain, inline)]

> It does fix the resizing problem.  However, now my entry in
> window-size-change-functions doesn't run at all, and so the font size in
> the new frame is wrong.
>
> I'm not sure whether this is a bug, but it might count as a change that
> should be called out in NEWS?  window-size-change-functions is no longer
> guaranteed to be called when frames are simply created.

The reason why I have to delay applying 'frame-inhibit-implied-resize'
in "normal" use is that people want the number of lines and columns
shown by the window manager when they drag frame borders with the mouse
match exactly the values specified in 'initial-frame-alist'.  OTOH, one
reason for implementing 'frame-inhibit-implied-resize' was to make using
Emacs with tiling WMs simpler.  Hence instead of all the tribulations
with running spw/scale-default from 'window-size-change-functions' we
should be able to find a better solution.

With the patch attached would

(defun spw/sway-completing-read (prompt collection &rest optional-args)
  (let* ((frame-inhibit-implied-resize 'force)
	 (frame (make-frame `((title . "Emacs Sway input")
			      (minibuffer . only)
			      (display . ,(getenv "WAYLAND_DISPLAY"))))))

    (set-face-attribute 'default frame :height 120)

    (unwind-protect
	(with-selected-frame frame
	  (set-window-scroll-bars (minibuffer-window frame) 0 nil 0 nil t)
	  (apply #'completing-read prompt collection optional-args))
      (delete-frame frame))))

do what you want?

> I'm not sure what you mean "while the function with the same name
> returned false" -- there isn't a function called
> frame_inhibit_implied_resize, I think?

Right.  I meant the function frame_inhibit_resize.

martin

[frame-inhibit-implied-resize-force.diff (text/x-patch, attachment)]

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

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: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on
 recent master
Date: Wed, 19 Feb 2025 13:10:50 +0800

Hello,

On Tue 18 Feb 2025 at 11:08am +01, martin rudalics wrote:

> OTOH, one reason for implementing 'frame-inhibit-implied-resize' was
> to make using Emacs with tiling WMs simpler.  Hence instead of all the
> tribulations with running spw/scale-default from
> 'window-size-change-functions' we should be able to find a better
> solution.
>
> With the patch attached would
>
> (defun spw/sway-completing-read (prompt collection &rest optional-args)
>   (let* ((frame-inhibit-implied-resize 'force)
> 	 (frame (make-frame `((title . "Emacs Sway input")
> 			      (minibuffer . only)
> 			      (display . ,(getenv "WAYLAND_DISPLAY"))))))
>
>     (set-face-attribute 'default frame :height 120)
>
>     (unwind-protect
> 	(with-selected-frame frame
> 	  (set-window-scroll-bars (minibuffer-window frame) 0 nil 0 nil t)
> 	  (apply #'completing-read prompt collection optional-args))
>       (delete-frame frame))))
>
> do what you want?

Actually, your patch is even better than that.
The following works as expected, now:

--8<---------------cut here---------------start------------->8---
(defun spw/scale-default (frame)
  (set-face-attribute 'default frame :height 120))
(add-to-list 'window-size-change-functions #'spw/scale-default)

(defun spw/sway-completing-read (prompt collection &rest optional-args)
  (let* ((frame-inhibit-implied-resize 'force)
	 (frame (make-frame `((title . "Emacs Sway input")
			      (minibuffer . only)
			      (display . ,(getenv "WAYLAND_DISPLAY"))))))
    (with-selected-frame frame
      (apply #'completing-read prompt collection optional-args))))
--8<---------------cut here---------------end--------------->8---

The reason that this is better for me is that my spw/scale-default is
just a dummy reproducer.  My actual window-size-change-functions entry
is more complicated, and long predates spw/sway-completing-read.
I've included it at the bottom of this message

My point is: I am not trying to use window-size-change-functions to work
around anything.  It's just that this value for
window-size-change-functions I alrady have stopped working properly in
the case of spw/sway-completing-read, recently.

It would be okay if I just had to call my window-size-change-functions
entry from spw/sway-completing-read.  I am not myself in a position to
judge whether having a `force' entry makes sense.  If you think it does,
then that's fine.

>> I'm not sure what you mean "while the function with the same name
>> returned false" -- there isn't a function called
>> frame_inhibit_implied_resize, I think?
>
> Right.  I meant the function frame_inhibit_resize.

Ah.  Do you still want me to do any testing with that?

=*=*=*=

--8<---------------cut here---------------start------------->8---
(custom-theme-set-faces
 'user
 '(default ((t (:weight medium :height 105 :foundry "SRC" :family "Hack"))))
 '(variable-pitch ((t (:weight regular :height 120
		       :foundry "bitstream" :family "Bitstream Charter")))))

(defun spw/maybe-scale-basic-faces (frame)
  "Entry for `window-size-change-functions' to increase font sizes,
relative to those set by the call to `custom-theme-set-faces' above, for
frames on wide monitors, except where doing so would itself prevent fitting
two 80-column windows side-by-side in the frame."
  (when (display-graphic-p frame)
    (let ((wide-monitor-p (> (cadddr (assoc 'geometry
					    (frame-monitor-attributes frame)))
			     1635)))
      (when (or wide-monitor-p
		;; Check whether a previous call made any changes we might
		;; need to undo if FRAME has moved to a smaller display.
		(not (eq scroll-bar-mode
			 (frame-parameter frame 'vertical-scroll-bars)))
		(= (face-attribute 'default :height frame) 120)
		(= (face-attribute 'variable-pitch :height frame) 151))
	(let* ;; Above 1635 you can scale up and still fit two 80-col windows.
	      ;; Below 1315 you can't fit the two windows even w/o scaling up.
	      ((medium-p (> 1635 (frame-pixel-width frame) 1315))
	       (scale-up-p (and wide-monitor-p (not medium-p))))
	  (modify-frame-parameters
	   frame
	   `(;; Can fit two 80-col windows only if we disable scroll bars.
	     (vertical-scroll-bars . ,(and (not (and wide-monitor-p medium-p))
					   scroll-bar-mode))))
	  ;; Check Emacs found the relevant font on this window system, else
	  ;; our height values might be invalid.
	  (when (find-font (font-spec :foundry "SRC" :family "Hack") frame)
	    (set-face-attribute 'default frame
				:height (if scale-up-p 120 105)))
	  (when (find-font (font-spec :foundry "bitstream"
				      :family "Bitstream Charter")
			   frame)
	    (set-face-attribute 'variable-pitch frame
				:height (if scale-up-p 151 120))))))))

(add-to-list 'window-size-change-functions #'spw/maybe-scale-basic-faces)
--8<---------------cut here---------------end--------------->8---

-- 
Sean Whitton

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

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

> Actually, your patch is even better than that.
> The following works as expected, now:
[...]
> The reason that this is better for me is that my spw/scale-default is
> just a dummy reproducer.  My actual window-size-change-functions entry
> is more complicated, and long predates spw/sway-completing-read.
> I've included it at the bottom of this message

Note one caveat from the Elisp manual:

   • Window change functions should not create or delete windows or
     change the buffer, size or selection status of any window because
     there is no guarantee that the information about such a change will
     be propagated to other window change functions.  If at all, any
     such change should be executed only by the last function listed by
     the default value of ‘window-state-change-hook’.

> It would be okay if I just had to call my window-size-change-functions
> entry from spw/sway-completing-read.  I am not myself in a position to
> judge whether having a `force' entry makes sense.  If you think it does,
> then that's fine.

So IIUC installing the 'force' entry fixes your bug.  Right?

>> Right.  I meant the function frame_inhibit_resize.
>
> Ah.  Do you still want me to do any testing with that?

No.

Thanks, martin

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

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: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on
 recent master
Date: Wed, 19 Feb 2025 17:42:32 +0800

Hello,

On Wed 19 Feb 2025 at 10:19am +01, martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

>> Actually, your patch is even better than that.
>> The following works as expected, now:
> [...]
>> The reason that this is better for me is that my spw/scale-default is
>> just a dummy reproducer.  My actual window-size-change-functions entry
>> is more complicated, and long predates spw/sway-completing-read.
>> I've included it at the bottom of this message
>
> Note one caveat from the Elisp manual:
>
>    • Window change functions should not create or delete windows or
>      change the buffer, size or selection status of any window because
>      there is no guarantee that the information about such a change will
>      be propagated to other window change functions.  If at all, any
>      such change should be executed only by the last function listed by
>      the default value of ‘window-state-change-hook’.

Hmm, does changing the height of a face always count as changing the size?

>> It would be okay if I just had to call my window-size-change-functions
>> entry from spw/sway-completing-read.  I am not myself in a position to
>> judge whether having a `force' entry makes sense.  If you think it does,
>> then that's fine.
>
> So IIUC installing the 'force' entry fixes your bug.  Right?

Yes.

-- 
Sean Whitton

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

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

> Hmm, does changing the height of a face always count as changing the size?

If implied resizing changes the frame's size it can.  Principally, you
should not worry, especially if implied resizing is inhibited.  The
caveat is here so people will double-check whether their code works as
intended.  If it doesn't, the culprit might be in the wrong ordering of
functions on those hooks.  This might impact window-old-.. functions
values and those of 'old-selected-window' ...

martin

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

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: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on
 recent master
Date: Wed, 19 Feb 2025 18:46:17 +0800

Hello,

On Wed 19 Feb 2025 at 10:53am +01, martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

>> Hmm, does changing the height of a face always count as changing the size?
>
> If implied resizing changes the frame's size it can.  Principally, you
> should not worry, especially if implied resizing is inhibited.  The
> caveat is here so people will double-check whether their code works as
> intended.  If it doesn't, the culprit might be in the wrong ordering of
> functions on those hooks.  This might impact window-old-.. functions
> values and those of 'old-selected-window' ...

Cool, thanks.

So, are you thinking you'll install the 'force patch?

-- 
Sean Whitton

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

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

> So, are you thinking you'll install the 'force patch?

As soon as I know how to fix my commit settings, yes.

martin

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

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

>  > So, are you thinking you'll install the 'force patch?

Installed on master now.

Thanks, martin

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

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

Hello,

On Sun 23 Feb 2025 at 11:05am +01, martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

>>  > So, are you thinking you'll install the 'force patch?
>
> Installed on master now.

Looks good to me.  Thanks again.  Closing the bug.

-- 
Sean Whitton

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

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: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on recent
 master
Date: Sun, 23 Feb 2025 13:15:36 +0200

> Date: Sun, 23 Feb 2025 11:05:51 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 76275 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, shipmints <at> gmail.com
> 
>  >  > So, are you thinking you'll install the 'force patch?
> 
> Installed on master now.

Thanks, but could you please clarify the difference between the values
t and 'force' of frame-inhibit-implied-resize?  I'm confused by "no
resizing once a frame has obtained its initial size" vs "no implicit
resizing whenever a new frame is made".  This seems to imply that
there are several stages in the resizing, but they are not explicitly
described.

Message #67 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: Mon, 24 Feb 2025 09:52:53 +0100

> Thanks, but could you please clarify the difference between the values
> t and 'force' of frame-inhibit-implied-resize?  I'm confused by "no
> resizing once a frame has obtained its initial size" vs "no implicit
> resizing whenever a new frame is made".  This seems to imply that
> there are several stages in the resizing, but they are not explicitly
> described.

I've tried to be more verbose in the manual and the doc-string now.
Please have a look.

Thanks, martin

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

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: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on recent
 master
Date: Mon, 24 Feb 2025 21:42:22 +0200

> Date: Mon, 24 Feb 2025 09:52:53 +0100
> Cc: spwhitton <at> spwhitton.name, 76275 <at> debbugs.gnu.org, shipmints <at> gmail.com
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > Thanks, but could you please clarify the difference between the values
>  > t and 'force' of frame-inhibit-implied-resize?  I'm confused by "no
>  > resizing once a frame has obtained its initial size" vs "no implicit
>  > resizing whenever a new frame is made".  This seems to imply that
>  > there are several stages in the resizing, but they are not explicitly
>  > described.
> 
> I've tried to be more verbose in the manual and the doc-string now.
> Please have a look.

Thanks.  It's better, but I think we still need to improve it.

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?

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

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

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: Re: 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'?

Message #79 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: Fri, 28 Feb 2025 10:25:07 +0100

> Maybe we should instead explain which settings could cause resize with
> t, but not with 'force'?

Here with a GTK3 build I get the following (frame-pixel-height) /
(frame-total-lines) values:

emacs -Q ~> 792 / 36

emacs -Q --eval "(setopt frame-inhibit-implied-resize t)" ~> 751 / 34

emacs -Q --eval "(setopt frame-inhibit-implied-resize 'force)" ~> 751 / 34

So with a GTK build here the major difference is between nil and t and
there's no difference between t and 'force.  Yet Sean sees a difference
with t and 'force.

And with a Lucid build I get 830 / 37 in all cases.  What can I possibly
explain?  Can you see a difference with these three cases?

martin

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

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: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on recent
 master
Date: Fri, 28 Feb 2025 13:47:02 +0200

> Date: Fri, 28 Feb 2025 10:25:07 +0100
> Cc: spwhitton <at> spwhitton.name, 76275 <at> debbugs.gnu.org, shipmints <at> gmail.com
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > Maybe we should instead explain which settings could cause resize with
>  > t, but not with 'force'?
> 
> Here with a GTK3 build I get the following (frame-pixel-height) /
> (frame-total-lines) values:
> 
> emacs -Q ~> 792 / 36
> 
> emacs -Q --eval "(setopt frame-inhibit-implied-resize t)" ~> 751 / 34
> 
> emacs -Q --eval "(setopt frame-inhibit-implied-resize 'force)" ~> 751 / 34
> 
> So with a GTK build here the major difference is between nil and t and
> there's no difference between t and 'force.  Yet Sean sees a difference
> with t and 'force.
> 
> And with a Lucid build I get 830 / 37 in all cases.  What can I possibly
> explain?  Can you see a difference with these three cases?

If you understand why Sean sees a difference, please tell why, and I
will try to see how to document that.

Is the GTK case the only one you know of when these two settings yield
different effects?

Thanks.

Message #85 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: Fri, 28 Feb 2025 16:10:14 +0100

> If you understand why Sean sees a difference, please tell why, and I
> will try to see how to document that.

Maybe Sean can tell.  Note that with my examples I never set any
parameters, don't consults X resources and use no init file.  Results
might differ with any of these set or used.

> Is the GTK case the only one you know of when these two settings yield
> different effects?

The GTK build is the only one with an external tool bar.  With
'tool-bar-mode' turned off, all three examples produce the same height
of 792 pixels.

martin

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>, martin rudalics <rudalics <at> gmx.at>
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, 02 Mar 2025 16:05:47 +0800

Hello,

On Fri 28 Feb 2025 at 04:10pm +01, martin rudalics wrote:

>> If you understand why Sean sees a difference, please tell why, and I
>> will try to see how to document that.
>
> Maybe Sean can tell.  Note that with my examples I never set any
> parameters, don't consults X resources and use no init file.  Results
> might differ with any of these set or used.

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.

If you assume that window-size-change-functions are applied relatively
early in frame creation, and then read the current documentation, it all
makes sense: "ah yes, my window-size-change-functions entry was changing
the font size early, such that Emacs wouldn't consider the final initial
size of the frame to have been agreed, yet, until after my code has run.
So I need `force'."

But I don't know whether that is a correct assumption to make.

-- 
Sean Whitton

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

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76275 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>,
 shipmints <at> gmail.com
Subject: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on
 recent master
Date: Wed, 05 Mar 2025 09:07:28 +0800

Hello,

On Sun 02 Mar 2025 at 10:43am +01, martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> 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.

I'd be very happy to run some specific tests, if you can suggest some.

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 76275 <at> debbugs.gnu.org, rudalics <at> gmx.at, shipmints <at> gmail.com
Subject: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on
 recent master
Date: Sat, 15 Mar 2025 13:13:55 +0200

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 76275 <at> debbugs.gnu.org,  shipmints <at> gmail.com
> Date: Sun, 02 Mar 2025 16:05:47 +0800
> 
> Hello,
> 
> On Fri 28 Feb 2025 at 04:10pm +01, martin rudalics wrote:
> 
> >> If you understand why Sean sees a difference, please tell why, and I
> >> will try to see how to document that.
> >
> > Maybe Sean can tell.  Note that with my examples I never set any
> > parameters, don't consults X resources and use no init file.  Results
> > might differ with any of these set or used.
> 
> 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.
> 
> If you assume that window-size-change-functions are applied relatively
> early in frame creation, and then read the current documentation, it all
> makes sense: "ah yes, my window-size-change-functions entry was changing
> the font size early, such that Emacs wouldn't consider the final initial
> size of the frame to have been agreed, yet, until after my code has run.
> So I need `force'."
> 
> But I don't know whether that is a correct assumption to make.

So what changes in the documentation would you suggest, and where?

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Sean Whitton <spwhitton <at> spwhitton.name>
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: Sat, 15 Mar 2025 16:09:20 +0100

> So what changes in the documentation would you suggest, and where?

I'm afraid that neither Sean nor I can give you a satisfactory answer.
As I tried to mention in the manual already, Emacs fights with the WM
over the initial size of the frame.  That fight is particularly intense
with toolkits like GTK that make the initial size of a frame depend on
themes that specify the size of the title bar, tool bar, menu bar and
scroll bars relative to the default font size an Emacs user chooses.

The GTK documentation says

 * Note that for gtk_window_parse_geometry() to work as expected, it has
 * to be called when the window has its “final” size, i.e. after calling
 * gtk_widget_show_all() on the contents and gtk_window_set_geometry_hints()
 * on the window.

and god knows how often Emacs sends new set size hints when making a
frame.  And all this in a period where the WM does the calculations
needed to keep the outer frame size unchanged while Emacs counters them
with its own calculations to keep the size of the text area unchanged.

Setting 'frame-inhibit-implied-resize' to 'force' in that period can
help or harm and the outcome may depend on the GTK version and the WM
used.  It's a heuristic that might work or not.

martin

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

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: Re: bug#76275: 31.0.50; frame-inhibit-implied-resize broken on recent
 master
Date: Sat, 15 Mar 2025 18:12:04 +0200

> Date: Sat, 15 Mar 2025 16:09:20 +0100
> Cc: 76275 <at> debbugs.gnu.org, shipmints <at> gmail.com
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > So what changes in the documentation would you suggest, and where?
> 
> I'm afraid that neither Sean nor I can give you a satisfactory answer.

I'm still willing to wait for Sean to chime in, perhaps he does have
an idea.

In any case, if we cannot satisfactorily document this variable, the
prudent thing is to remove it from the manual.  Because that means its
use is only for experts who know the subtle aspects of the variable
and its effects.

> Setting 'frame-inhibit-implied-resize' to 'force' in that period can
> help or harm and the outcome may depend on the GTK version and the WM
> used.  It's a heuristic that might work or not.

One more reason not to document it.

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

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

Hello,

On Sat 15 Mar 2025 at 06:12pm +02, Eli Zaretskii wrote:

>> Date: Sat, 15 Mar 2025 16:09:20 +0100
>> Cc: 76275 <at> debbugs.gnu.org, shipmints <at> gmail.com
>> From: martin rudalics <rudalics <at> gmx.at>
>>
>>  > So what changes in the documentation would you suggest, and where?
>>
>> I'm afraid that neither Sean nor I can give you a satisfactory answer.
>
> I'm still willing to wait for Sean to chime in, perhaps he does have
> an idea.

I think we could describe that it is intended to work in terms of the
notion of "Emacs agreeing with the window manager on the size of the
initial frame" but also that this notion is not yet well-defined for
every single one of the large number of different window environments in
which Emacs already generally works well.

> In any case, if we cannot satisfactorily document this variable, the
> prudent thing is to remove it from the manual.  Because that means its
> use is only for experts who know the subtle aspects of the variable
> and its effects.

Currently the docstring and the manual are very similar.  So we could
merge the manual text into the docstring.  Then also add to the
docstring or in a code comment, that we would like to document this in
the manual again, once we have pinned down exactly when this agreement
between Emacs and the WM occurs, on more of the environments we support.

(Such as ones that are in fact quite commonly used, like mine.
 Wayland on GNU/Linux, especially Sway, is only increasing in adoption.)

For example, if we do get an alternative Emacs-for-Wayland to pgtk,
things might get a lot clearer.  Maybe the problems here are all in fact
Gtk issues (wouldn't be the first time!).  We'll see.

-- 
Sean Whitton

Previous Next

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