bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[David Fiander]

Using the below init file, and running emacs from the command line, the
initial frame seems to appear with the correct size but then shrinks
down. The frame created by pressing C-x 5 2 is the correct size.

;;; -*- lexical-binding: t; coding: utf-8; -*-

(set-face-attribute 'default nil :family "Noto Sans Mono" :weight 
'regular :height 160)

;; (set-frame-height nil 26)
;; (set-frame-width nil 90)
;; (push '(height . 26) default-frame-alist)
;; (push '(width . 90) default-frame-alist)



In GNU Emacs 29.1 (build 1, x86_64-unknown-freebsd13.2, GTK+ Version
  3.24.34, cairo version 1.17.4) of 2023-07-23 built on
  shawinigan.l.fiander.info
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: 13.2-RELEASE-p1

Configured using:
  'configure --with-xwidgets'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBXML2 MODULES NOTIFY KQUEUE PDUMPER PNG RSVG SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM XWIDGETS
GTK3 ZLIB

Important settings:
   value of $LANG: en_CA.UTF-8
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   show-paren-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
/home/david/.config/emacs/elpa/transient-20230602.2121/transient hides 
/usr/local/share/emacs/29.1/lisp/transient

Features:
(shadow sort mail-extr emacsbug message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util text-property-search mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tex-site pcase
slime-autoloads info package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv
bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal dbusbind
kqueue lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 69368 9195)
  (symbols 48 8126 0)
  (strings 32 24572 1933)
  (string-bytes 1 797086)
  (vectors 16 16446)
  (vector-slots 8 246591 10008)
  (floats 8 44 15)
  (intervals 56 227 0)
  (buffers 976 10))

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[Eli Zaretskii]

> Date: Sun, 23 Jul 2023 15:02:45 -0500
> From: David Fiander <david@fiander.info>
> 
> Using the below init file, and running emacs from the command line, the
> initial frame seems to appear with the correct size but then shrinks
> down.

Shrinks down to what size?

> The frame created by pressing C-x 5 2 is the correct size.
> 
> ;;; -*- lexical-binding: t; coding: utf-8; -*-
> 
> (set-face-attribute 'default nil :family "Noto Sans Mono" :weight 
> 'regular :height 160)
> 
> ;; (set-frame-height nil 26)
> ;; (set-frame-width nil 90)
> ;; (push '(height . 26) default-frame-alist)
> ;; (push '(width . 90) default-frame-alist)

Po Lu, any ideas?

Did we change anything in this regard since Emacs 28?

Thanks.

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 23 Jul 2023 15:02:45 -0500
>> From: David Fiander <david@fiander.info>
>> 
>> Using the below init file, and running emacs from the command line, the
>> initial frame seems to appear with the correct size but then shrinks
>> down.
>
> Shrinks down to what size?
>
>> The frame created by pressing C-x 5 2 is the correct size.
>> 
>> ;;; -*- lexical-binding: t; coding: utf-8; -*-
>> 
>> (set-face-attribute 'default nil :family "Noto Sans Mono" :weight 
>> 'regular :height 160)
>> 
>> ;; (set-frame-height nil 26)
>> ;; (set-frame-width nil 90)
>> ;; (push '(height . 26) default-frame-alist)
>> ;; (push '(width . 90) default-frame-alist)
>
> Po Lu, any ideas?
>
> Did we change anything in this regard since Emacs 28?
>
> Thanks.

David, are you using KWin by any chance?  Along with a GTK+ build of
Emacs?

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[David Fiander]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]



On 2023-07-24 07:05, Po Lu wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> Date: Sun, 23 Jul 2023 15:02:45 -0500
>>> From: David Fiander <david@fiander.info>
>>>
>>> Using the below init file, and running emacs from the command line, the
>>> initial frame seems to appear with the correct size but then shrinks
>>> down.
>>
>> Shrinks down to what size?

When I resize the window, the emacs tooltip says that it's 89x25. 
xwininfo says that it's 752x504 pixels. The characters displayed in the 
window are the same size as when I run 28.2. See the attached screenshot.

When I use the same init file with emacs 28.2, the emacs tooltip also 
says 89x25, but xwininfo reports that it is 1215x824 pixels

> 
> David, are you using KWin by any chance?  Along with a GTK+ build of
> Emacs?

I'm using gtk+, but not pgtk. The window manager is XFCE.

- David

[-- Attachment #2: emacs-29.jpg --]
[-- Type: image/jpeg, Size: 70134 bytes --]

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

David Fiander <david@fiander.info> writes:

> On 2023-07-24 07:05, Po Lu wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>>> Date: Sun, 23 Jul 2023 15:02:45 -0500
>>>> From: David Fiander <david@fiander.info>
>>>>
>>>> Using the below init file, and running emacs from the command line, the
>>>> initial frame seems to appear with the correct size but then shrinks
>>>> down.
>>>
>>> Shrinks down to what size?
>
> When I resize the window, the emacs tooltip says that it's
> 89x25. xwininfo says that it's 752x504 pixels. The characters
> displayed in the window are the same size as when I run 28.2. See the
> attached screenshot.
>
> When I use the same init file with emacs 28.2, the emacs tooltip also
> says 89x25, but xwininfo reports that it is 1215x824 pixels

What happens if you set:

  (setq frame-resize-pixelwise t)

in your early-init.el?

> I'm using gtk+, but not pgtk. The window manager is XFCE.

Thanks.  Does the problem still occur with a no-toolkit build (one with
--with-x-toolkit=no?)

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[David Fiander]

On 2023-07-24 08:27, Po Lu wrote:
> David Fiander <david@fiander.info> writes:
> 
>> On 2023-07-24 07:05, Po Lu wrote:
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> Date: Sun, 23 Jul 2023 15:02:45 -0500
>>>>> From: David Fiander <david@fiander.info>
>>>>>
>>>>> Using the below init file, and running emacs from the command line, the
>>>>> initial frame seems to appear with the correct size but then shrinks
>>>>> down.
>>>>
>>>> Shrinks down to what size?
>>
>> When I resize the window, the emacs tooltip says that it's
>> 89x25. xwininfo says that it's 752x504 pixels. The characters
>> displayed in the window are the same size as when I run 28.2. See the
>> attached screenshot.
>>
>> When I use the same init file with emacs 28.2, the emacs tooltip also
>> says 89x25, but xwininfo reports that it is 1215x824 pixels
> 
> What happens if you set:
> 
>    (setq frame-resize-pixelwise t)
> 
> in your early-init.el?

The same "small window" behaviour.
> 
>> I'm using gtk+, but not pgtk. The window manager is XFCE.
> 
> Thanks.  Does the problem still occur with a no-toolkit build (one with
> --with-x-toolkit=no?)

both with and with frame-resize-pixelwise, the window appears "full 
size", blinks to the small size, and the resizes correctly for the given 
font.

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

David Fiander <david@fiander.info> writes:

> The same "small window" behaviour.

Are you sure that the font size of the default face is being set before
the default frame is created?

>>> I'm using gtk+, but not pgtk. The window manager is XFCE.
>> Thanks.  Does the problem still occur with a no-toolkit build (one
>> with
>> --with-x-toolkit=no?)
>
> both with and with frame-resize-pixelwise, the window appears "full
> size", blinks to the small size, and the resizes correctly for the
> given font.

Because given this, I believe Emacs is attempting to constrain the pixel
size of the frame to its character width and height, as it does upon
each change to the default font.

This is intentional behavior that didn't always work correctly in Emacs
28.

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[Jim Porter]

I see this issue too. I'm running GNU/Linux with the Cinnamon desktop 
environment (which is derived from GNOME 3).

> What happens if you set:
> 
>    (setq frame-resize-pixelwise t)
> 
> in your early-init.el?

This seems to help with the reduced test case, but not my full config 
(I'm not sure why yet).

> Thanks.  Does the problem still occur with a no-toolkit build (one with
> --with-x-toolkit=no?)

This seems to work, though the frame flashes back and forth between 
sizes a couple times before settling on the right size.

I found a related issue that might make this easier to diagnose: when I 
run the following in Emacs 28.2, it correctly sets the default face 
height for the current frame. With Emacs 29.1, it flashes for a second 
at the correct size, then reverts to the default:

emacs -Q --eval "(set-face-attribute 'default (selected-frame) :height 70)"

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[Jim Porter]

On 7/24/2023 9:33 AM, Jim Porter wrote:
> I found a related issue that might make this easier to diagnose: when I 
> run the following in Emacs 28.2, it correctly sets the default face 
> height for the current frame. With Emacs 29.1, it flashes for a second 
> at the correct size, then reverts to the default:
> 
> emacs -Q --eval "(set-face-attribute 'default (selected-frame) :height 70)"

At least for this case, I narrowed the regression down to the following 
commit:

   commit 52d4c98cec0901ef5cc1c55d5b3b33ac9d9c519f
   Author: Vincent Bernat <bernat@luffy.cx>
   Date:   Tue Oct 25 23:02:16 2022 +0200

       Fix detection of DPI changes in builds without Xft

       * src/xsettings.c (apply_xft_settings) [!HAVE_XFT]: Support
       XSETTINGS changes in non-XFT builds.  (Bug#43128)

So maybe the DPI detection in this commit is happening too late, or the 
code should bail out if the user has already customized the default face 
height?

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jim Porter <jporterbugs@gmail.com> writes:

> On 7/24/2023 9:33 AM, Jim Porter wrote:
>> I found a related issue that might make this easier to diagnose:
>> when I run the following in Emacs 28.2, it correctly sets the
>> default face height for the current frame. With Emacs 29.1, it
>> flashes for a second at the correct size, then reverts to the
>> default:
>> emacs -Q --eval "(set-face-attribute 'default (selected-frame)
>> :height 70)"
>
> At least for this case, I narrowed the regression down to the
> following commit:
>
>   commit 52d4c98cec0901ef5cc1c55d5b3b33ac9d9c519f
>   Author: Vincent Bernat <bernat@luffy.cx>
>   Date:   Tue Oct 25 23:02:16 2022 +0200
>
>       Fix detection of DPI changes in builds without Xft
>
>       * src/xsettings.c (apply_xft_settings) [!HAVE_XFT]: Support
>       XSETTINGS changes in non-XFT builds.  (Bug#43128)
>
> So maybe the DPI detection in this commit is happening too late, or
> the code should bail out if the user has already customized the
> default face height?

I see; then the problem is that the DPI provided by the settings manager
differs from the DPI specified in the Xft.dpi resource at display
initialization time.

So Emacs detects a change to the display density after reading the new
DPI from the settings manager, and sends a `font-render' event.  That
event later causes all fonts to be reinitialized with the new scaling
factor.

The easy workaround for Emacs 29 is for the user to set Xft.dpi to the
value provided by the settings manager, as any other value points to a
misconfiguration anyway.  For Emacs 30, using the settings manager to
provide the initial value in the first place should be a more robust
solution.

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[David Fiander]

On 2023-07-24 19:09, Po Lu wrote:
> 
> The easy workaround for Emacs 29 is for the user to set Xft.dpi to the
> value provided by the settings manager, as any other value points to a
> misconfiguration anyway.  For Emacs 30, using the settings manager to
> provide the initial value in the first place should be a more robust
> solution.

My display is running at 96dpi, so I just add

	Xft.dpi: 96

to my .Xresources file and reload it? Because I've done that, and I'm 
still seeing the blinking and the small initial frame.

But just to be clear, when you say "Settings manager", you mean the XFCE 
(or other desktop equivalent) settings manager?

- David

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[Jim Porter]

On 7/24/2023 5:09 PM, Po Lu via Bug reports for GNU Emacs, the Swiss 
army knife of text editors wrote:
> Jim Porter <jporterbugs@gmail.com> writes:
>> At least for this case, I narrowed the regression down to the
>> following commit:
>>
>>    commit 52d4c98cec0901ef5cc1c55d5b3b33ac9d9c519f
>>    Author: Vincent Bernat <bernat@luffy.cx>
>>    Date:   Tue Oct 25 23:02:16 2022 +0200
>>
>>        Fix detection of DPI changes in builds without Xft
>>
>>        * src/xsettings.c (apply_xft_settings) [!HAVE_XFT]: Support
>>        XSETTINGS changes in non-XFT builds.  (Bug#43128)
>>
>> So maybe the DPI detection in this commit is happening too late, or
>> the code should bail out if the user has already customized the
>> default face height?
> 
> I see; then the problem is that the DPI provided by the settings manager
> differs from the DPI specified in the Xft.dpi resource at display
> initialization time.

In my case, it seems that the only thing that's changed inside 
'apply_xfg_settings' is the hint style. If I comment out the hint style 
block, everything works correctly.

However, that did lead me to debug further, and I think the issue really 
lies elsewhere; the commit I mentioned (likely) just uncovered a latent 
bug. Starting from "emacs -Q", I eval the following (after the frame is 
all set up, of course):

   (set-face-attribute 'default (selected-frame) :height 70)
   ;; The frame and default face both shrink as expected.
   (reconsider-frame-fonts (selected-frame))
   ;; The frame and default face now revert to their old sizes.

Is this behavior correct? I'd expect that 'reconsider-frame-fonts' would 
take my setting from 'set-face-attribute' into consideration, but it 
seems to throw it out.

In practice, this issue could come up if a user calls 
'set-face-attribute' as above and then changes their system's font 
settings. It would cause the user-set face height to get thrown out.

If the user does something like this:

   (set-face-attribute 'default t :height 70)

And then opens up a new frame, the behavior is even stranger. Every time 
I change the system font hinting style, the new frame gets larger.

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jim Porter <jporterbugs@gmail.com> writes:

> In my case, it seems that the only thing that's changed inside
> 'apply_xfg_settings' is the hint style. If I comment out the hint
> style block, everything works correctly.
>
> However, that did lead me to debug further, and I think the issue
> really lies elsewhere; the commit I mentioned (likely) just uncovered
> a latent bug. Starting from "emacs -Q", I eval the following (after
> the frame is all set up, of course):
>
>   (set-face-attribute 'default (selected-frame) :height 70)
>   ;; The frame and default face both shrink as expected.
>   (reconsider-frame-fonts (selected-frame))
>   ;; The frame and default face now revert to their old sizes.
>
> Is this behavior correct? I'd expect that 'reconsider-frame-fonts'
> would take my setting from 'set-face-attribute' into consideration,
> but it seems to throw it out.

Ugh.  No, I didn't intend for `reconsider-frame-fonts' to behave in this
manner.  I can't help wondering why this wasn't caught until the release
candidate of all things.

ISTM that more attributes of the default face should also be preserved
whenever its definition is merged into a frame and used in
`default_font_parameter'.

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  64809@debbugs.gnu.org,  David Fiander
>  <david@fiander.info>
> Date: Tue, 25 Jul 2023 10:08:25 +0800
> 
> I can't help wondering why this wasn't caught until the release
> candidate of all things.

Because evidently people don't start seriously using and testing the
pretest until it's a few days from being released.

Don't worry, the fix for this will not go into Emacs 29.1, unless you
_really_ surprise me by its simplicity and safety.  After all, this
issue is merely a minor annoyance, not a big problem, especially if
one uses Emacs As God Intended and starts it only once in a blue moon.
Jim actually said he usually doesn't use GUI Emacs...

So feel free to design and implement a sound solution; no rush.

TIA

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[Jim Porter]

On 7/25/2023 4:56 AM, Eli Zaretskii wrote:
> Don't worry, the fix for this will not go into Emacs 29.1, unless you
> _really_ surprise me by its simplicity and safety.  After all, this
> issue is merely a minor annoyance, not a big problem, especially if
> one uses Emacs As God Intended and starts it only once in a blue moon.
> Jim actually said he usually doesn't use GUI Emacs...

Well, not on the development builds. (I usually run a minimal 
configuration in the terminal when testing things.) I do use GUI Emacs a 
fair amount otherwise though. However, I agree that this is a minor 
annoyance, and should be easy enough to work around for the time being 
with a couple of well-placed advices anyway.

Still, in the future I'll make sure to find time to test under a wider 
variety of configurations earlier in the development process to catch 
issues like this before an RC. I'm surprised no one noticed this issue 
until now either, but I guess most users don't use the development 
builds heavily.

bug#64809: 29.1; Initial frame is wrong size when dimensions specified in init file

[David Fiander]

I normally run emacs as a daemon, and this problem appears for the first 
frame that I create with the daemon, but all subsequent frames are fine. 
Adding a (reconsider-frame-fonts) to my complicated "pick the right face 
& size" function in my init file pretty much eliminates the problem for 
me, even on the initial frame.

- David

On 7/25/23 10:42, Jim Porter wrote:
> On 7/25/2023 4:56 AM, Eli Zaretskii wrote:
>> Don't worry, the fix for this will not go into Emacs 29.1, unless you
>> _really_ surprise me by its simplicity and safety.  After all, this
>> issue is merely a minor annoyance, not a big problem, especially if
>> one uses Emacs As God Intended and starts it only once in a blue moon.
>> Jim actually said he usually doesn't use GUI Emacs...
>
> Well, not on the development builds. (I usually run a minimal 
> configuration in the terminal when testing things.) I do use GUI Emacs 
> a fair amount otherwise though. However, I agree that this is a minor 
> annoyance, and should be easy enough to work around for the time being 
> with a couple of well-placed advices anyway.
>
> Still, in the future I'll make sure to find time to test under a wider 
> variety of configurations earlier in the development process to catch 
> issues like this before an RC. I'm surprised no one noticed this issue 
> until now either, but I guess most users don't use the development 
> builds heavily.