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

Previous Next

Full log

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

Previous Next

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