GNU bug report logs - #68880
30.0.50; [pgtk] Theme customization is not applied by custom-theme-set-faces until theme is re-enabled

Previous Next

To reply to this bug, email your comments to 68880 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; [pgtk] Theme customization is not applied by
 custom-theme-set-faces until theme is re-enabled
Date: Fri, 2 Feb 2024 01:14:12 +0200

To reproduce, put this into .emacs:

(add-hook
  'after-init-hook
  (lambda ()
    (load-theme 'adwaita t)

    (custom-theme-set-faces
     'adwaita
     '(font-lock-comment-face ((t (:foreground "yellow")))))))

Then run emacs -Q.

When the PGTK port is used, the comment face's foreground won't be
yellow. With other ports (e.g. GTK3 or Lucid), it is.

The use of after-init-hook itself it not crucial - you can just as well
enable the theme using 'M-x load-theme' and then evaluate the
custom-theme-set-faces form.

There is some text on the splash screen with font-lock-comment-face
applied, so you should see the effect right away.

In GNU Emacs 30.0.50 (build 333, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.18.0) of 2024-02-02 built on potemkin
Repository revision: 71b5d5a9799a37948b2e8cca125a59e2bfb71e96
Repository branch: master
System Description: Ubuntu 23.10

Configured using:
 'configure --with-pgtk'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PGTK PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP
XIM GTK3 ZLIB

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

From: Po Lu <luangruo <at> yahoo.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 68880 <at> debbugs.gnu.org
Subject: Re: bug#68880: 30.0.50; [pgtk] Theme customization is not applied
 by custom-theme-set-faces until theme is re-enabled
Date: Sat, 03 Feb 2024 14:41:36 +0800

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> To reproduce, put this into .emacs:
>
> (add-hook
>   'after-init-hook
>   (lambda ()
>     (load-theme 'adwaita t)
>
>     (custom-theme-set-faces
>      'adwaita
>      '(font-lock-comment-face ((t (:foreground "yellow")))))))
>
> Then run emacs -Q.

Upon rereading your description, it appears as though you're reporting
that `emacs -Q' does not load the user's initialization files, while it
does in the non-PGTK builds.  Needless to say, if true, that is a severe
bug!

> When the PGTK port is used, the comment face's foreground won't be
> yellow. With other ports (e.g. GTK3 or Lucid), it is.
>
> The use of after-init-hook itself it not crucial - you can just as well
> enable the theme using 'M-x load-theme' and then evaluate the
> custom-theme-set-faces form.
>
> There is some text on the splash screen with font-lock-comment-face
> applied, so you should see the effect right away.

I can reproduce this, thanks.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 68880 <at> debbugs.gnu.org
Subject: Re: bug#68880: 30.0.50; [pgtk] Theme customization is not applied by
 custom-theme-set-faces until theme is re-enabled
Date: Sat, 3 Feb 2024 19:11:01 +0200

On 03/02/2024 08:41, Po Lu wrote:
> Dmitry Gutov <dmitry <at> gutov.dev> writes:
> 
>> To reproduce, put this into .emacs:
>>
>> (add-hook
>>    'after-init-hook
>>    (lambda ()
>>      (load-theme 'adwaita t)
>>
>>      (custom-theme-set-faces
>>       'adwaita
>>       '(font-lock-comment-face ((t (:foreground "yellow")))))))
>>
>> Then run emacs -Q.
> 
> Upon rereading your description, it appears as though you're reporting
> that `emacs -Q' does not load the user's initialization files, while it
> does in the non-PGTK builds.  Needless to say, if true, that is a severe
> bug!

Not sure it relates to the user initialization files: like I say below, 
the same scenario and the result can be reproduced interactively after 
Emacs has initialized.

>> When the PGTK port is used, the comment face's foreground won't be
>> yellow. With other ports (e.g. GTK3 or Lucid), it is.
>>
>> The use of after-init-hook itself it not crucial - you can just as well
>> enable the theme using 'M-x load-theme' and then evaluate the
>> custom-theme-set-faces form.
>>
>> There is some text on the splash screen with font-lock-comment-face
>> applied, so you should see the effect right away.
> 
> I can reproduce this, thanks.

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: 68880 <at> debbugs.gnu.org, Dmitry Gutov <dmitry <at> gutov.dev>
Subject: Re: bug#68880: 30.0.50; [pgtk] Theme customization is not applied by
 custom-theme-set-faces until theme is re-enabled
Date: Sat, 8 Mar 2025 06:54:31 -0300

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> To reproduce, put this into .emacs:
>
> (add-hook
>   'after-init-hook
>   (lambda ()
>     (load-theme 'adwaita t)
>
>     (custom-theme-set-faces
>      'adwaita
>      '(font-lock-comment-face ((t (:foreground "yellow")))))))
>
> Then run emacs -Q.
>
> When the PGTK port is used, the comment face's foreground won't be
> yellow. With other ports (e.g. GTK3 or Lucid), it is.

I can't reproduce it.  As expected, with emacs -Q, the lambda function
never gets called.

So, I see the same on the 3 builds I've tried (GTK3, Lucid,
PGTK): Emacs starts with the default theme.

> The use of after-init-hook itself it not crucial - you can just as well
> enable the theme using 'M-x load-theme' and then evaluate the
> custom-theme-set-faces form.

If I start with emacs -Q and then evaluate the forms inside the
lambda function, I can't reproduce it either, because I see the exact
same thing on the 3 builds: adwaita theme gets loaded and enabled, but
the font-lock-comment-face customization doesn't get customized to
yellow.

IOW, I can reproduce, but it's not pgtk specific.


I think this is related to Bug#76685.  But since I can't reproduce the
bug exactly as reported, I would like to check before merging the bugs.

Previous Next

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