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

Previous Next

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