GNU bug report logs -
#58912
29.0.50; set-face-attribute call in init.el has no lasting effect
Previous Next
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Mon, 31 Oct 2022 00:45:02 UTC
Severity: normal
Merged with 59271,
59283
Found in version 29.0.50
Done: Po Lu <luangruo <at> yahoo.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58912 in the body.
You can then email your comments to 58912 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Mon, 31 Oct 2022 00:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 31 Oct 2022 00:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
1. Have a line in init.el like
(set-face-attribute 'default nil :height 110 :weight 'semi-light :family
"Cascadia Mono")
2. Start Emacs. See the graphical frame get resized briefly during
startup, but then go back to the default monospaced system font (Ubuntu
Mono in my case), with the default font size.
To reproduce without wiping ~/.emacs.d, create
/tmp/.emacs.d/init.el with that one line
and run
emacs -Q -l /tmp/.emacs.d/init.el
with a recent enough build from master.
If I then evaluate that line in the running Emacs session (visit the
file, go to eol, press C-x C-e), the face attributes get set correctly,
with expected visual result.
There was a similar report in emacs-devel from Tim Cross 2 days ago, but
it apparently resolved itself after 'fc-cache -v' and rebooting. I
haven't tried rebooting, but the command itself didn't help.
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0) of 2022-10-29 built on potemkin
Repository revision: 81d7827f34f1ac1108891421a44b36554776b04e
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Ubuntu 20.04.5 LTS
Configured using:
'configure --with-x-toolkit=gtk3'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Mon, 31 Oct 2022 13:34:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 58912 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 31 Oct 2022 02:44:24 +0200
> From: Dmitry Gutov <dgutov <at> yandex.ru>
>
> 1. Have a line in init.el like
>
> (set-face-attribute 'default nil :height 110 :weight 'semi-light :family
> "Cascadia Mono")
>
> 2. Start Emacs. See the graphical frame get resized briefly during
> startup, but then go back to the default monospaced system font (Ubuntu
> Mono in my case), with the default font size.
I cannot reproduce this. The settings in the init file, both the font
family and its size, get reflected in the default face's font for me.
But I'm not on an X/GTK-based system, so I suspect something like
xsettings or gsettings or somesuch are responsible for the resetting
of the default face's font. Perhaps Po Lu could help.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Mon, 31 Oct 2022 13:58:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Mon, 31 Oct 2022 02:44:24 +0200
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> 1. Have a line in init.el like
>>
>> (set-face-attribute 'default nil :height 110 :weight 'semi-light :family
>> "Cascadia Mono")
>>
>> 2. Start Emacs. See the graphical frame get resized briefly during
>> startup, but then go back to the default monospaced system font (Ubuntu
>> Mono in my case), with the default font size.
>
> I cannot reproduce this. The settings in the init file, both the font
> family and its size, get reflected in the default face's font for me.
> But I'm not on an X/GTK-based system, so I suspect something like
> xsettings or gsettings or somesuch are responsible for the resetting
> of the default face's font. Perhaps Po Lu could help.
Thanks. Dimitry, do you have font-use-system-font set to any non-nil
value? If so, the font will be changed back upon startup, in order to
reflect the system font.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Mon, 31 Oct 2022 14:12:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 58912 <at> debbugs.gnu.org (full text, mbox):
On 31.10.2022 15:57, Po Lu via Bug reports for GNU Emacs, the Swiss army
knife of text editors wrote:
> Thanks. Dimitry, do you have font-use-system-font set to any non-nil
> value? If so, the font will be changed back upon startup, in order to
> reflect the system font.
Nope. That value is nil.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Tue, 01 Nov 2022 00:34:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> Nope. That value is nil.
Does it happen in an -nw session as well? (Obviously, you have to set
some face attribute other than the font to test.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Tue, 01 Nov 2022 00:57:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 58912 <at> debbugs.gnu.org (full text, mbox):
On 01.11.2022 02:32, Po Lu via Bug reports for GNU Emacs, the Swiss army
knife of text editors wrote:
> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>
>> Nope. That value is nil.
> Does it happen in an -nw session as well? (Obviously, you have to set
> some face attribute other than the font to test.)
Depends on the attribute.
If I set :foreground, it is retained both under X and -nw. :background too.
If I set :underline, it is retained under -nw, but not under X. But that
includes an older branch which I haven't merged master to for a while,
which I use daily.
Underline similarly appears briefly during startup but then goes away.
Same for :inverse-video. All under X (-nw keeps them).
Said branch doesn't touch anything display-related, so it should behave
like master a few months ago.
The difference seems to be that the most recent master also does that to
attributes :height and :family.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Tue, 01 Nov 2022 01:02:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> Depends on the attribute.
>
> If I set :foreground, it is retained both under X and -nw. :background too.
>
> If I set :underline, it is retained under -nw, but not under X. But
> that includes an older branch which I haven't merged master to for a
> while, which I use daily.
>
> Underline similarly appears briefly during startup but then goes
> away. Same for :inverse-video. All under X (-nw keeps them).
>
> Said branch doesn't touch anything display-related, so it should
> behave like master a few months ago.
>
> The difference seems to be that the most recent master also does that
> to attributes :height and :family.
If you run "xrdb -query", what is printed?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Tue, 01 Nov 2022 02:21:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 58912 <at> debbugs.gnu.org (full text, mbox):
I see the same symptoms as Dmitry. I'm running a current Debian Testing
system, Gnome, Wayland.
Namely:
1) emacs -Q --> the 'default font family is the Gnome system monospace font.
2) emacs -Q -l test.el --> still uses the Gnome system mono font despite
setting the 'default face otherwise early in init.
I changed the .el file to this:
(set-face-attribute
'default nil :height 110 :weight 'semi-light :family
"Cascadia Mono")
(debug-on-entry #'set-face-attribute)
And the origin of the font change back to the system defaults is this:
Debugger entered--entering a function:
* set-face-attribute(default #<frame *scratch* - GNU Emacs at naz 0x55ad505df290> :width normal :weight normal :slant normal :font "Go Mono 11")
font-setting-change-default-font(":0" nil)
dynamic-setting-handle-config-changed-event((config-changed-event font-render ":0"))
funcall-interactively(dynamic-setting-handle-config-changed-event (config-changed-event font-render ":0"))
call-interactively(dynamic-setting-handle-config-changed-event nil [(config-changed-event font-render ":0")])
command-execute(dynamic-setting-handle-config-changed-event nil [(config-changed-event font-render ":0")] t)
It looks like `font-setting-change-default-font' is pulling the system
font (in my case "Go Mono") from the frame, which probably wasn't
modified by the earlier `set-face-attribute` call. To confirm I changed
test.el to this:
(set-face-attribute
'default nil :height 110 :weight 'semi-light :family
"Cascadia Mono")
(dolist (frame (frame-list))
(let ((frame-font
(or (font-get (face-attribute 'default :font frame 'default)
:user-spec)
(frame-parameter frame 'font-parameter))))
(message "frame %S frame-font %S" frame frame-font)))
And re-run "emacs -Q -l test.el" and get this in *Messages*:
frame #<frame *scratch* - GNU Emacs at naz 0x55d8362ca7f0> frame-font "Go Mono 11"
So I change test.el yet again to have only this:
(set-frame-font "Cascadia Mono")
...and that font change sticks. `set-frame-font` is what is called by
the Options -> Set Default Font menu item and has logic to walk through
frames and set their parameters accordingly.
And again to have only this:
(set-frame-font (font-spec :height 110
:weight 'semi-light
:family "Cascadia Mono"))
...I wonder if setting the 'default face attribute in 'early-init.el'
would be enough, too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Tue, 01 Nov 2022 02:59:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Matt Armstrong <matt <at> rfc20.org> writes:
> I see the same symptoms as Dmitry. I'm running a current Debian Testing
> system, Gnome, Wayland.
>
> Namely:
>
> 1) emacs -Q --> the 'default font family is the Gnome system monospace font.
>
> 2) emacs -Q -l test.el --> still uses the Gnome system mono font despite
> setting the 'default face otherwise early in init.
>
> I changed the .el file to this:
>
> (set-face-attribute
> 'default nil :height 110 :weight 'semi-light :family
> "Cascadia Mono")
> (debug-on-entry #'set-face-attribute)
>
> And the origin of the font change back to the system defaults is this:
>
> Debugger entered--entering a function:
> * set-face-attribute(default #<frame *scratch* - GNU Emacs at naz 0x55ad505df290> :width normal :weight normal :slant normal :font "Go Mono 11")
> font-setting-change-default-font(":0" nil)
> dynamic-setting-handle-config-changed-event((config-changed-event font-render ":0"))
> funcall-interactively(dynamic-setting-handle-config-changed-event (config-changed-event font-render ":0"))
> call-interactively(dynamic-setting-handle-config-changed-event nil [(config-changed-event font-render ":0")])
> command-execute(dynamic-setting-handle-config-changed-event nil [(config-changed-event font-render ":0")] t)
>
> It looks like `font-setting-change-default-font' is pulling the system
> font (in my case "Go Mono") from the frame, which probably wasn't
> modified by the earlier `set-face-attribute` call. To confirm I changed
> test.el to this:
>
> (set-face-attribute
> 'default nil :height 110 :weight 'semi-light :family
> "Cascadia Mono")
> (dolist (frame (frame-list))
> (let ((frame-font
> (or (font-get (face-attribute 'default :font frame 'default)
> :user-spec)
> (frame-parameter frame 'font-parameter))))
> (message "frame %S frame-font %S" frame frame-font)))
>
> And re-run "emacs -Q -l test.el" and get this in *Messages*:
>
> frame #<frame *scratch* - GNU Emacs at naz 0x55d8362ca7f0> frame-font "Go Mono 11"
>
> So I change test.el yet again to have only this:
>
> (set-frame-font "Cascadia Mono")
>
> ...and that font change sticks. `set-frame-font` is what is called by
> the Options -> Set Default Font menu item and has logic to walk through
> frames and set their parameters accordingly.
>
> And again to have only this:
>
> (set-frame-font (font-spec :height 110
> :weight 'semi-light
> :family "Cascadia Mono"))
>
>
> ...I wonder if setting the 'default face attribute in 'early-init.el'
> would be enough, too.
Doesn't it only do that if font-use-system-font is t? Here is the
relevant part of dynamic-setting.el:
;; Just redraw the existing fonts on all frames:
(dolist (f frame-list)
(let ((frame-font
(or (font-get (face-attribute 'default :font f 'default)
:user-spec) <=====
this should return "Cascadia Mono"... what does it return for you?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Tue, 01 Nov 2022 10:26:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 58912 <at> debbugs.gnu.org (full text, mbox):
On 01.11.2022 03:01, Po Lu wrote:
> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>
>> Depends on the attribute.
>>
>> If I set :foreground, it is retained both under X and -nw. :background too.
>>
>> If I set :underline, it is retained under -nw, but not under X. But
>> that includes an older branch which I haven't merged master to for a
>> while, which I use daily.
>>
>> Underline similarly appears briefly during startup but then goes
>> away. Same for :inverse-video. All under X (-nw keeps them).
>>
>> Said branch doesn't touch anything display-related, so it should
>> behave like master a few months ago.
>>
>> The difference seems to be that the most recent master also does that
>> to attributes :height and :family.
> If you run "xrdb -query", what is printed?
$ xrdb -query
*customization: -color
Xft.dpi: 192
Xft.antialias: 1
Xft.hinting: 0
Xft.hintstyle: hintnone
Xft.rgba: rgb
Xcursor.size: 48
Xcursor.theme: DMZ-White
In case this is still relevant.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Tue, 01 Nov 2022 10:36:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> $ xrdb -query
> *customization: -color
> Xft.dpi: 192
> Xft.antialias: 1
> Xft.hinting: 0
> Xft.hintstyle: hintnone
> Xft.rgba: rgb
> Xcursor.size: 48
> Xcursor.theme: DMZ-White
>
> In case this is still relevant.
Thanks, that looks fine. Matt, could you show what that prints on your
system?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Tue, 01 Nov 2022 17:38:02 GMT)
Full text and
rfc822 format available.
Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):
I have the same problem.
GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
$ xrdb -query
emacs.font: DejaVu Sans Mono-12
/tmp/test.el:
(custom-set-faces
'(default ((t (:family "DejaVu Sans Mono" :foundry "PfEd" :slant normal :weight normal :height 120 :width normal)))))
emacs -Q -nbc -l /tmp/test.el
shows incorrect font
font-use-system-font
=> nil
(face-attribute 'default :font (selected-frame) 'default)
#<font-object "-PfEd-DejaVu Sans Mono-regular-normal-normal-*-13-*-*-*-m-0-ISO10646-1">
but after applying the following patch I get correct fonts:
(face-attribute 'default :font (selected-frame) 'default)
#<font-object "-PfEd-DejaVu Sans Mono-regular-normal-normal-*-16-*-*-*-m-0-iso10646-1">
diff --git a/src/xsettings.c b/src/xsettings.c
index 15e7ff54995..403117f8271 100644
--- a/src/xsettings.c
+++ b/src/xsettings.c
@@ -806,9 +806,7 @@ read_settings (Display_Info *dpyinfo, struct xsettings *settings)
apply_xft_settings (Display_Info *dpyinfo,
struct xsettings *settings)
{
-#if defined HAVE_XFT \
- || (defined USE_CAIRO && defined CAIRO_HAS_FC_FONT \
- && defined CAIRO_HAS_FT_FONT)
+#if defined HAVE_XFT
FcPattern *pat;
struct xsettings oldsettings;
bool changed = false;
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Tue, 01 Nov 2022 17:38:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Wed, 02 Nov 2022 00:56:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> I have the same problem.
>
> GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
>
> $ xrdb -query
> emacs.font: DejaVu Sans Mono-12
>
> /tmp/test.el:
> (custom-set-faces
> '(default ((t (:family "DejaVu Sans Mono" :foundry "PfEd" :slant normal :weight normal :height 120 :width normal)))))
>
> emacs -Q -nbc -l /tmp/test.el
> shows incorrect font
>
> font-use-system-font
> => nil
>
> (face-attribute 'default :font (selected-frame) 'default)
> #<font-object "-PfEd-DejaVu Sans Mono-regular-normal-normal-*-13-*-*-*-m-0-ISO10646-1">
>
> but after applying the following patch I get correct fonts:
>
> (face-attribute 'default :font (selected-frame) 'default)
> #<font-object "-PfEd-DejaVu Sans Mono-regular-normal-normal-*-16-*-*-*-m-0-iso10646-1">
>
> diff --git a/src/xsettings.c b/src/xsettings.c
> index 15e7ff54995..403117f8271 100644
> --- a/src/xsettings.c
> +++ b/src/xsettings.c
> @@ -806,9 +806,7 @@ read_settings (Display_Info *dpyinfo, struct xsettings *settings)
> apply_xft_settings (Display_Info *dpyinfo,
> struct xsettings *settings)
> {
> -#if defined HAVE_XFT \
> - || (defined USE_CAIRO && defined CAIRO_HAS_FC_FONT \
> - && defined CAIRO_HAS_FT_FONT)
> +#if defined HAVE_XFT
> FcPattern *pat;
> struct xsettings oldsettings;
> bool changed = false;
That is unrelated: previously xsettings font rendering events were not
sent on Cairo builds, but that led to a bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Wed, 02 Nov 2022 17:52:03 GMT)
Full text and
rfc822 format available.
Message #47 received at 58912 <at> debbugs.gnu.org (full text, mbox):
> That is unrelated: previously xsettings font rendering events were not
> sent on Cairo builds, but that led to a bug.
So fixing one bug exposed another bug?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Wed, 02 Nov 2022 21:14:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> $ xrdb -query
>> *customization: -color
>> Xft.dpi: 192
>> Xft.antialias: 1
>> Xft.hinting: 0
>> Xft.hintstyle: hintnone
>> Xft.rgba: rgb
>> Xcursor.size: 48
>> Xcursor.theme: DMZ-White
>>
>> In case this is still relevant.
>
> Thanks, that looks fine. Matt, could you show what that prints on your
> system?
naz% xrdb -query
*customization: -color
Xcursor.size: 24
Xcursor.theme: Adwaita
Xft.antialias: 1
Xft.dpi: 96
Xft.hinting: 1
Xft.hintstyle: hintslight
Xft.rgba: none
(by the way, my Gnome is Wayland and I'm on a pgtk Emacs)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Wed, 02 Nov 2022 21:56:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Matt Armstrong <matt <at> rfc20.org> writes:
>
>> I see the same symptoms as Dmitry. I'm running a current Debian Testing
>> system, Gnome, Wayland.
[...]
>> ...I wonder if setting the 'default face attribute in 'early-init.el'
>> would be enough, too.
>
> Doesn't it only do that if font-use-system-font is t?
I am running these tests with emacs -Q, so `font-use-system-font' is
nil.
It looks like `font-use-system-font' variable has an effect only when
`event` is 'monospace-font-name. What I see is a 'font-render event
happening after `init.el`. I never see a 'monospace-font-name event
(even if I change the system monospace font with Gnome Tweaks).
I just did another run, placing the below into `test.el' and running
"emacs -Q -l test.el".
----------------------------------------------------------------------
(trace-function #'dynamic-setting-handle-config-changed-event)
(trace-function #'font-setting-change-default-font)
(trace-function #'set-face-attribute)
(trace-function #'face-attribute)
(trace-function #'font-get)
(set-face-attribute
'default nil :height 110 :weight 'semi-light :family
"Cascadia Mono")
----------------------------------------------------------------------
And this is what I see in "*trace-output*" after startup. So, it looks
like `font-setting-change-default-font' is getting "IBM Plex Mono 11"
from the :user-spec of a Cascadia Mono font object, which seems strange.
In this case "IBM Plex Mono 11" is what I have set as my system's
default monospace font (in Gnome settings).
======================================================================
1 -> (set-face-attribute default nil :height 110 :weight semi-light :family "Cascadia Mono")
1 <- set-face-attribute: nil
======================================================================
1 -> (dynamic-setting-handle-config-changed-event (config-changed-event font-render ":0"))
| 2 -> (font-setting-change-default-font ":0" nil)
| | 3 -> (face-attribute default :font #<frame *scratch* - GNU Emacs at naz 0x5598c59e4a70> default)
| | 3 <- face-attribute: #<font-object "-SAJA-Cascadia Mono-semilight-normal-normal-*-15-*-*-*-m-0-iso10646-1">
| | 3 -> (font-get #<font-object "-SAJA-Cascadia Mono-semilight-normal-normal-*-15-*-*-*-m-0-iso10646-1"> :user-spec)
| | 3 <- font-get: "IBM Plex Mono 11"
| | 3 -> (set-face-attribute default #<frame *scratch* - GNU Emacs at naz 0x5598c59e4a70> :width normal :weight normal :slant normal :font "IBM Plex Mono 11")
| | 3 <- set-face-attribute: nil
| 2 <- font-setting-change-default-font: nil
1 <- dynamic-setting-handle-config-changed-event: nil
======================================================================
Also, I confirmed that moving the "test.el" code into early-init.el is
enough to "fix" the problem. It looks like that runs even before the
default face is configured for the first time.
For completeness, here is how I'm running Emacs:
In GNU Emacs 29.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version
3.24.34, cairo version 1.16.0) of 2022-11-02 built on naz
Repository revision: 05f5d978ae70c4849a5c47865d62301d27317a8a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12201003
System Description: Debian GNU/Linux bookworm/sid
Configured using:
'configure 'CFLAGS=-O2 -g3''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Message[Notmuch]
Minor modes in effect:
company-mode: t
msb-mode: t
display-time-mode: t
flyspell-mode: t
mml-mode: t
global-tab-line-mode: t
tab-line-mode: t
envrc-global-mode: t
envrc-mode: t
shell-dirtrack-mode: t
auto-insert-mode: t
keyfreq-autosave-mode: t
keyfreq-mode: t
savehist-mode: t
icomplete-vertical-mode: t
icomplete-mode: t
editorconfig-mode: t
which-key-mode: t
electric-pair-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tab-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
column-number-mode: t
line-number-mode: t
auto-fill-function: message-do-auto-fill
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
temp-buffer-resize-mode: t
abbrev-mode: t
Load-path shadows:
~/env/elisp/ol-notmuch hides /home/matt/.config/emacs/elpa/ol-notmuch-20220428.1337/ol-notmuch
/home/matt/.config/emacs/elpa/transient-20221028.1430/transient hides /home/matt/git/e/daily-driver/lisp/transient
Features:
(shadow emacsbug descr-text magit-base flymake-proc flymake compile
copyright shortdoc tabify imenu man eudc-capf eudc cus-edit pp cus-start
cus-load eudc-vars vc-git vc-dispatcher bug-reference help-fns
radix-tree misearch multi-isearch textsec uni-scripts idna-mapping
ucs-normalize uni-confusable textsec-check sort company-oddmuse
company-keywords company-etags etags fileloop xref company-gtags
company-dabbrev-code company-dabbrev company-files company-clang
company-capf company-cmake company-semantic company-template
company-bbdb company mail-extr smerge-mode diff mm-archive protbuf msb
time mule-util notmuch notmuch-tree notmuch-jump notmuch-hello
notmuch-show notmuch-print notmuch-crypto notmuch-mua notmuch-message
notmuch-draft notmuch-maildir-fcc notmuch-address notmuch-company
notmuch-parser notmuch-wash diff-mode coolj goto-addr icalendar
diary-lib diary-loaddefs notmuch-tag crm notmuch-lib notmuch-compat
pcase hl-line flyspell ispell org-element avl-tree generator ol-w3m
ol-rmail ol-mhe ol-irc ol-info org-habit org-agenda org-refile ol-gnus
nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
gnus-sum gnus-group gnus-undo gnus-start gnus-dbus dbus gnus-cloud
nnimap nnmail mail-source utf7 nnoo parse-time gnus-spec gnus-int
gnus-range message sendmail yank-media rfc822 mml mml-sec epa derived
epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win
ol-eww eww xdg url-queue shr pixel-fill kinsoku url-file svg xml dom
puny mm-url gnus nnheader gnus-util text-property-search mail-utils
range wid-edit mm-util mail-prsvr ol-doi org-link-doi ol-docview
doc-view filenotify jka-compr image-mode exif dired dired-loaddefs
ol-bibtex ol-bbdb tab-line server envrc inheritenv web-mode disp-table
nix-mode ffap thingatpt smie nix-repl nix-shell nix-store magit-section
dash compat-27 compat-26 nix-log nix-instantiate nix-shebang nix-format
nix dirtrack ob-shell shell ob-ruby ob-python python compat compat-macs
ob-dot org-protocol org ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-macro org-footnote org-src ob-comint org-pcomplete pcomplete comint
ansi-osc ansi-color ring org-list org-faces org-entities noutline
outline org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic
bibtex iso8601 time-date org-keys oc org-loaddefs find-func cal-menu
calendar cal-loaddefs finder-inf ol-notmuch ol rx org-compat org-macs
format-spec skeleton autoinsert advice keyfreq project edmacro kmacro
warnings icons savehist icomplete editorconfig editorconfig-core
editorconfig-core-handle editorconfig-fnmatch which-key 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 eieio eieio-core password-cache json subr-x map
byte-opt url-vars cl-extra help-mode cl-macs gv cl-seq elec-pair
use-package use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core cl-loaddefs
cl-lib bytecomp byte-compile info bazel-autoloads
clang-format+-autoloads clang-format-autoloads cmake-mode-autoloads
d-mode-autoloads debbugs-autoloads editorconfig-autoloads elpy-autoloads
company-autoloads envrc-autoloads exec-path-from-shell-autoloads
flymake-ruby-autoloads flymake-easy-autoloads flymake-yamllint-autoloads
go-mode-autoloads google-c-style-autoloads graphviz-dot-mode-autoloads
highlight-indentation-autoloads inheritenv-autoloads magit-autoloads
git-commit-autoloads markdown-mode-autoloads meson-mode-autoloads
nix-mode-autoloads magit-section-autoloads dash-autoloads
nixpkgs-fmt-autoloads ol-notmuch-autoloads notmuch-autoloads
orderless-autoloads org-drill-autoloads ox-hugo-autoloads
persist-autoloads pylint-autoloads pyvenv-autoloads s-autoloads
shfmt-autoloads reformatter-autoloads tomelr-autoloads
transient-autoloads use-package-autoloads bind-key-autoloads
vertico-autoloads web-mode-autoloads which-key-autoloads
with-editor-autoloads compat-autoloads yaml-mode-autoloads
yasnippet-autoloads 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 dbusbind inotify 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 712036 95075)
(symbols 48 49974 129)
(strings 32 270832 9811)
(string-bytes 1 6789117)
(vectors 16 94289)
(vector-slots 8 1982956 191956)
(floats 8 457 689)
(intervals 56 5349 1679)
(buffers 984 31))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Thu, 03 Nov 2022 06:24:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 58912 <at> debbugs.gnu.org (full text, mbox):
> From: Matt Armstrong <matt <at> rfc20.org>
> Cc: Dmitry Gutov <dgutov <at> yandex.ru>, Eli Zaretskii <eliz <at> gnu.org>,
> 58912 <at> debbugs.gnu.org
> Date: Wed, 02 Nov 2022 14:55:18 -0700
>
> Also, I confirmed that moving the "test.el" code into early-init.el is
> enough to "fix" the problem.
In case there's any doubt, we don't want this kind of solutions to be
the fix for such problems. early-init.el should be used for a very
small number of customizations that must take place early on. This
one is not one of them.
Thanks for the other data you collected.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Thu, 03 Nov 2022 07:18:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> In case there's any doubt, we don't want this kind of solutions to be
> the fix for such problems. early-init.el should be used for a very
> small number of customizations that must take place early on. This
> one is not one of them.
I agree. I think the problem is something in the code that handles
font-render events not working as intended: it is only supposed to cause
all fonts displayed on all frames to be reopened.
Won't:
(clear-face-cache t)
(clear-font-cache)
work for that as well?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Thu, 03 Nov 2022 08:40:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 58912 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Matt Armstrong <matt <at> rfc20.org>, dgutov <at> yandex.ru, 58912 <at> debbugs.gnu.org
> Date: Thu, 03 Nov 2022 15:17:31 +0800
>
> I think the problem is something in the code that handles
> font-render events not working as intended: it is only supposed to cause
> all fonts displayed on all frames to be reopened.
>
> Won't:
>
> (clear-face-cache t)
> (clear-font-cache)
>
> work for that as well?
Where can I read about the semantics of this event? I don't think I
understand well enough what it means and how we should support it in
Emacs.
Also, any idea why we are delivered this event during startup?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Thu, 03 Nov 2022 11:10:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Where can I read about the semantics of this event?
I don't know.
> I don't think I understand well enough what it means and how we should
> support it in Emacs.
The event is sent when the system says all fonts must be reopened,
because the settings used by the underlying font library have changed.
> Also, any idea why we are delivered this event during startup?
No idea. TBH, it sounds like a bug in the PGTK GSettings code I will
look into.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Sat, 05 Nov 2022 18:52:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Matt Armstrong <matt <at> rfc20.org>
>> Cc: Dmitry Gutov <dgutov <at> yandex.ru>, Eli Zaretskii <eliz <at> gnu.org>,
>> 58912 <at> debbugs.gnu.org
>> Date: Wed, 02 Nov 2022 14:55:18 -0700
>>
>> Also, I confirmed that moving the "test.el" code into early-init.el is
>> enough to "fix" the problem.
>
> In case there's any doubt, we don't want this kind of solutions to be
> the fix for such problems. early-init.el should be used for a very
> small number of customizations that must take place early on. This
> one is not one of them.
>
> Thanks for the other data you collected.
It might be a clue to the bug. Namely, when the 'default face's family
is set in init.el I see this in the
dynamic-setting-handle-config-changed-event ->
font-setting-change-default-font calls:
3 -> (font-get #<font-object "-SAJA-Cascadia Mono-semilight-normal-normal-*-15-*-*-*-m-0-iso10646-1"> :user-spec)
3 <- font-get: "IBM Plex Mono 11"
When set in early-init.el I see something like this:
3 -> (font-get #<font-object "-SAJA-Cascadia Mono-semilight-normal-normal-*-15-*-*-*-m-0-iso10646-1"> :user-spec)
3 <- font-get: "Cascadia Mono 11"
I don't know what a font-object's :user-spec property is, or why it is
apparently wrong in the first case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Sat, 05 Nov 2022 19:04:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 58912 <at> debbugs.gnu.org (full text, mbox):
> From: Matt Armstrong <matt <at> rfc20.org>
> Cc: luangruo <at> yahoo.com, dgutov <at> yandex.ru, 58912 <at> debbugs.gnu.org
> Date: Sat, 05 Nov 2022 11:50:54 -0700
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > In case there's any doubt, we don't want this kind of solutions to be
> > the fix for such problems. early-init.el should be used for a very
> > small number of customizations that must take place early on. This
> > one is not one of them.
> >
> > Thanks for the other data you collected.
>
> It might be a clue to the bug.
Of course, and that's why this information is valuable. My point is
that it cannot be a solution to have users customize the default face
in early-init.el.
> Namely, when the 'default face's family
> is set in init.el I see this in the
> dynamic-setting-handle-config-changed-event ->
> font-setting-change-default-font calls:
>
> 3 -> (font-get #<font-object "-SAJA-Cascadia Mono-semilight-normal-normal-*-15-*-*-*-m-0-iso10646-1"> :user-spec)
> 3 <- font-get: "IBM Plex Mono 11"
>
> When set in early-init.el I see something like this:
>
> 3 -> (font-get #<font-object "-SAJA-Cascadia Mono-semilight-normal-normal-*-15-*-*-*-m-0-iso10646-1"> :user-spec)
> 3 <- font-get: "Cascadia Mono 11"
>
> I don't know what a font-object's :user-spec property is
See font.c, where this property is put on the font object.
> or why it is apparently wrong in the first case.
That's the important question to answer, yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Tue, 08 Nov 2022 19:05:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 58912 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I have the same problem.
>
> $ xrdb -query
> emacs.font: DejaVu Sans Mono-12
>
> (custom-set-faces
> '(default ((t (:family "DejaVu Sans Mono" :foundry "PfEd" :slant normal :weight normal :height 120 :width normal)))))
These settings now cause such a strange effect that tabs have gigantic heights
on the tab-bar, while tab text still stays small. Such sizes make sense only
when used with double scaling on a HiDPI display, but no scaling is really used
in this case:
[tab-big.png (image/png, inline)]
Forcibly Merged 58912 59271 59283.
Request was from
Po Lu <luangruo <at> yahoo.com>
to
control <at> debbugs.gnu.org
.
(Tue, 15 Nov 2022 11:49:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Sat, 19 Nov 2022 06:03:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 58912 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 01.11.2022 03:01, Po Lu wrote:
>> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>>
>>> Depends on the attribute.
>>>
>>> If I set :foreground, it is retained both under X and -nw. :background too.
>>>
>>> If I set :underline, it is retained under -nw, but not under X. But
>>> that includes an older branch which I haven't merged master to for a
>>> while, which I use daily.
>>>
>>> Underline similarly appears briefly during startup but then goes
>>> away. Same for :inverse-video. All under X (-nw keeps them).
>>>
>>> Said branch doesn't touch anything display-related, so it should
>>> behave like master a few months ago.
>>>
>>> The difference seems to be that the most recent master also does that
>>> to attributes :height and :family.
>> If you run "xrdb -query", what is printed?
>
> $ xrdb -query
> *customization: -color
> Xft.dpi: 192
> Xft.antialias: 1
> Xft.hinting: 0
> Xft.hintstyle: hintnone
> Xft.rgba: rgb
> Xcursor.size: 48
> Xcursor.theme: DMZ-White
>
> In case this is still relevant.
Would you please see if Emacs now behaves satisfactorily in this regard?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58912
; Package
emacs
.
(Sat, 19 Nov 2022 14:11:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 58912 <at> debbugs.gnu.org (full text, mbox):
On 19.11.2022 08:02, Po Lu via Bug reports for GNU Emacs, the Swiss army
knife of text editors wrote:
> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>
>> On 01.11.2022 03:01, Po Lu wrote:
>>> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>>>
>>>> Depends on the attribute.
>>>>
>>>> If I set :foreground, it is retained both under X and -nw. :background too.
>>>>
>>>> If I set :underline, it is retained under -nw, but not under X. But
>>>> that includes an older branch which I haven't merged master to for a
>>>> while, which I use daily.
>>>>
>>>> Underline similarly appears briefly during startup but then goes
>>>> away. Same for :inverse-video. All under X (-nw keeps them).
>>>>
>>>> Said branch doesn't touch anything display-related, so it should
>>>> behave like master a few months ago.
>>>>
>>>> The difference seems to be that the most recent master also does that
>>>> to attributes :height and :family.
>>> If you run "xrdb -query", what is printed?
>> $ xrdb -query
>> *customization: -color
>> Xft.dpi: 192
>> Xft.antialias: 1
>> Xft.hinting: 0
>> Xft.hintstyle: hintnone
>> Xft.rgba: rgb
>> Xcursor.size: 48
>> Xcursor.theme: DMZ-White
>>
>> In case this is still relevant.
> Would you please see if Emacs now behaves satisfactorily in this regard?
As I previously wrote in bug#59306, the fonts seem fine now, and they
have been the reason for me filing this bug report (#58912). But the
frame size is still jumpy (something I only noticed later).
So we could close this bug and continue in bug#59306, I suppose?
Reply sent
to
Po Lu <luangruo <at> yahoo.com>
:
You have taken responsibility.
(Sun, 20 Nov 2022 00:36:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
bug acknowledged by developer.
(Sun, 20 Nov 2022 00:36:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 58912-done <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> As I previously wrote in bug#59306, the fonts seem fine now, and they
> have been the reason for me filing this bug report (#58912). But the
> frame size is still jumpy (something I only noticed later).
>
> So we could close this bug and continue in bug#59306, I suppose?
Yes, I guess so.
Reply sent
to
Po Lu <luangruo <at> yahoo.com>
:
You have taken responsibility.
(Sun, 20 Nov 2022 00:36:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Gabriel <gabriel376 <at> hotmail.com>
:
bug acknowledged by developer.
(Sun, 20 Nov 2022 00:36:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Po Lu <luangruo <at> yahoo.com>
:
You have taken responsibility.
(Sun, 20 Nov 2022 00:36:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Mickey Petersen <mickey <at> fyeah.org>
:
bug acknowledged by developer.
(Sun, 20 Nov 2022 00:36:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 18 Dec 2022 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 185 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.