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

Previous Next

Full log

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

Previous Next

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