GNU bug report logs - #64809
29.1; Initial frame is wrong size when dimensions specified in init file

Previous Next

Package: emacs;

Reported by: David Fiander <david <at> fiander.info>

Date: Sun, 23 Jul 2023 20:04:01 UTC

Severity: normal

Merged with 64812

Found in version 29.1

Full log


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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 64809 <at> debbugs.gnu.org,
 David Fiander <david <at> fiander.info>
Subject: Re: bug#64809: 29.1; Initial frame is wrong size when dimensions
 specified in init file
Date: Mon, 24 Jul 2023 18:14:55 -0700
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 <at> gmail.com> writes:
>> At least for this case, I narrowed the regression down to the
>> following commit:
>>
>>    commit 52d4c98cec0901ef5cc1c55d5b3b33ac9d9c519f
>>    Author: Vincent Bernat <bernat <at> 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.




This bug report was last modified 1 year and 328 days ago.

Previous Next


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