GNU bug report logs - #77928
[PATCH] use-package :custom-face is meant to behave like custom-set-face

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77928 in the body.
You can then email your comments to 77928 AT debbugs.gnu.org in the normal way.

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

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

From: Michael Shields <shields <at> msrl.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] use-package :custom-face is meant to behave like
 custom-set-face
Date: Sat, 19 Apr 2025 13:41:01 -0700

[Message part 1 (text/plain, inline)]

The attached patch fixes a bug where migrating a face spec from custom.el
to use-package :custom-face results in a surprising behavior change: the
new spec is overlaid on the default value instead of replacing it. This
seems to have been an unintended consequence of
https://github.com/jwiegley/use-package/issues/934.

[Message part 2 (text/html, inline)]

[0001-Fix-use-package-custom-face-to-set-face-defface-spec.patch (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Shields <shields <at> msrl.com>, John Wiegley <johnw <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org
Subject: Re: bug#77928: [PATCH] use-package :custom-face is meant to behave
 like custom-set-face
Date: Sun, 20 Apr 2025 09:10:47 +0300

> From: Michael Shields <shields <at> msrl.com>
> Date: Sat, 19 Apr 2025 13:41:01 -0700
> 
> The attached patch fixes a bug where migrating a face spec from custom.el to use-package :custom-face
> results in a surprising behavior change: the new spec is overlaid on the default value instead of replacing it.
> This seems to have been an unintended consequence of
> https://github.com/jwiegley/use-package/issues/934.

John, any comments?

> From 748e620fe2d286a853f4030bba16c99470387a1b Mon Sep 17 00:00:00 2001
> From: Michael Shields <shields <at> msrl.com>
> Date: Sat, 19 Apr 2025 12:58:26 -0700
> Subject: [PATCH] Fix use-package :custom-face to set face-defface-spec
> 
> By default, `face-set-spec' sets the override face spec, so the supplied
> face attributes are combined with the default, rather than replacing
> them.  This was a behavior change that was an apparently unintended
> consequence of commit 6b344a9.
> 
> Also set the `face-modified' property, which causes Customize to flag
> the face as changed outside Customize.
> 
> * doc/misc/use-package.texi (Faces):
> * lisp/use-package/use-package-core.el (use-package-handler/:custom-face):
> (use-package):
> * test/lisp/use-package/use-package-tests.el (use-package-test/:custom-face-1):
> (use-package-test/:custom-face-2):
> (use-package-test/:custom-face-3):
> (use-package-test/:custom-face-4):
> ---
>  doc/misc/use-package.texi                  |  5 +++
>  lisp/use-package/use-package-core.el       |  8 +++--
>  test/lisp/use-package/use-package-tests.el | 40 ++++++++++++++++++----
>  3 files changed, 45 insertions(+), 8 deletions(-)
> 
> diff --git a/doc/misc/use-package.texi b/doc/misc/use-package.texi
> index c14e7b77d23..cdae8d6e662 100644
> --- a/doc/misc/use-package.texi
> +++ b/doc/misc/use-package.texi
> @@ -1457,6 +1457,11 @@ Faces
>  @end group
>  @end lisp
>  
> +Similarly to @code{:custom} (@pxref{User options}), this allows
> +configuring customizable faces outside of Customize (@pxref{Saving
> +Customizations,,, emacs, GNU Emacs Manual}).  Using both systems to
> +configure the same face can lead to confusing results.
> +
>  @node Hiding minor modes
>  @section Hiding minor modes with diminish and delight
>  @cindex hiding minor modes
> diff --git a/lisp/use-package/use-package-core.el b/lisp/use-package/use-package-core.el
> index c04053c22ac..4b63d985604 100644
> --- a/lisp/use-package/use-package-core.el
> +++ b/lisp/use-package/use-package-core.el
> @@ -1584,7 +1584,11 @@ use-package-normalize/:custom-face
>  (defun use-package-handler/:custom-face (name _keyword args rest state)
>    "Generate use-package custom-face keyword code."
>    (use-package-concat
> -   (mapcar #'(lambda (def) `(apply #'face-spec-set (backquote ,def))) args)
> +   (mapcar #'(lambda (def)
> +               `(progn
> +                  (apply #'face-spec-set (append (backquote ,def) '(face-defface-spec)))
> +                  (put ',(car def) 'face-modified t)))
> +           args)
>     (use-package-process-keywords name rest state)))
>  
>  ;;;; :init
> @@ -1848,7 +1852,7 @@ use-package
>  :custom          Call `Custom-set' or `set-default' with each variable
>                   definition without modifying the Emacs `custom-file'.
>                   (compare with `custom-set-variables').
> -:custom-face     Call `custom-set-faces' with each face definition.
> +:custom-face     Call `face-spec-set' with each face definition.
>  :ensure          Loads the package using package.el if necessary.
>  :pin             Pin the package to an archive.
>  :vc              Install the package directly from a version control system
> diff --git a/test/lisp/use-package/use-package-tests.el b/test/lisp/use-package/use-package-tests.el
> index 8554b37d5b8..b221c5de5c1 100644
> --- a/test/lisp/use-package/use-package-tests.el
> +++ b/test/lisp/use-package/use-package-tests.el
> @@ -1153,7 +1153,12 @@ use-package-test/:custom-face-1
>    (match-expansion
>     (use-package foo :custom-face (foo ((t (:background "#e4edfc")))))
>     `(progn
> -      (apply #'face-spec-set (backquote (foo ((t (:background "#e4edfc"))))))
> +      (progn
> +        (apply #'face-spec-set
> +               (append (backquote (foo ((t (:background "#e4edfc")))))
> +                       '(face-defface-spec))
> +               )
> +        (put 'foo 'face-modified t))
>        (require 'foo nil nil))))
>  
>  (ert-deftest use-package-test/:custom-face-2 ()
> @@ -1163,19 +1168,42 @@ use-package-test/:custom-face-2
>       (example-1-face ((t (:foreground "LightPink"))))
>       (example-2-face ((t (:foreground "LightGreen")))))
>     `(progn
> -      (apply #'face-spec-set
> -             (backquote (example-1-face ((t (:foreground "LightPink"))))))
> -      (apply #'face-spec-set
> -             (backquote (example-2-face ((t (:foreground "LightGreen"))))))
> +      (progn
> +        (apply #'face-spec-set
> +               (append (backquote (example-1-face ((t (:foreground "LightPink")))))
> +                       '(face-defface-spec)))
> +        (put 'example-1-face 'face-modified t))
> +      (progn
> +        (apply #'face-spec-set
> +               (append (backquote (example-2-face ((t (:foreground "LightGreen")))))
> +                       '(face-defface-spec)))
> +        (put 'example-2-face 'face-modified t))
>        (require 'example nil nil))))
>  
>  (ert-deftest use-package-test/:custom-face-3 ()
>    (match-expansion
>     (use-package foo :custom-face (foo ((t (:background "#e4edfc"))) face-defspec-spec))
>     `(progn
> -      (apply #'face-spec-set (backquote (foo ((t (:background "#e4edfc"))) face-defspec-spec)))
> +      (progn
> +        (apply #'face-spec-set
> +               (append (backquote (foo ((t (:background "#e4edfc"))) face-defspec-spec))
> +                       '(face-defface-spec)))
> +        (put 'foo 'face-modified t))
>        (require 'foo nil nil))))
>  
> +(ert-deftest use-package-test/:custom-face-4 ()
> +  (defface use-package-test/base-face '((t (:background "green"))) "")
> +  (defface use-package-test/face '((t (:inherit use-package-test/base-face))) "")
> +  (use-package emacs
> +    :custom-face
> +    (use-package-test/face ((t (:foreground "blue")))))
> +  (should (equal (face-foreground 'use-package-test/face nil t)
> +                 "blue"))
> +  (should (equal (face-background 'use-package-test/face nil t)
> +                 nil))
> +  (should (equal (get 'use-package-test/face 'face-modified)
> +                 t)))
> +
>  (ert-deftest use-package-test/:init-1 ()
>    (match-expansion
>     (use-package foo :init (init))
> -- 
> 2.49.0
> 

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

From: John Wiegley <johnw <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, Michael Shields <shields <at> msrl.com>
Subject: Re: bug#77928: [PATCH] use-package :custom-face is meant to behave
 like custom-set-face
Date: Thu, 24 Apr 2025 18:17:06 -0700

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

>> The attached patch fixes a bug where migrating a face spec from custom.el
>> to use-package :custom-face results in a surprising behavior change: the
>> new spec is overlaid on the default value instead of replacing it. This
>> seems to have been an unintended consequence of
>> https://github.com/jwiegley/use-package/issues/934.

> John, any comments?

Well, this patch would invalidate the current documentation:

     (use-package example
       :custom-face
       (example-1-face ((t (:foreground "LightPink"))))
       (example-2-face ((t (:foreground "LightGreen"))) face-defspec-spec))

It will remove the ability to specify a SPEC-TYPE argument in the declaration,
and instead would force it to always be `face-defface-spec', no? At the moment
the default uses `face-override-spec', when no such argument is provided.

If face-defface-spec is the desired default behaivor — while dropping the
current ability to customize that behavior in the declaration — I have no
objection, but the Texinfo example will need to be updated as well.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Michael Shields <shields <at> msrl.com>
To: John Wiegley <johnw <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77928 <at> debbugs.gnu.org
Subject: Re: bug#77928: [PATCH] use-package :custom-face is meant to behave
 like custom-set-face
Date: Thu, 24 Apr 2025 19:21:33 -0700

[Message part 1 (text/plain, inline)]

Ok, documentation updated.

It looks like the only reason a SPEC-TYPE argument is accepted was that
someone else was caught out by the unintended change to partial inheritance:
https://github.com/jwiegley/use-package/issues/1008

[Message part 2 (text/html, inline)]

[0002-Update-documentation.patch (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Shields <shields <at> msrl.com>, John Wiegley <johnw <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org
Subject: Re: bug#77928: [PATCH] use-package :custom-face is meant to behave
 like custom-set-face
Date: Sat, 26 Apr 2025 15:52:32 +0300

> From: Michael Shields <shields <at> msrl.com>
> Date: Sat, 19 Apr 2025 13:41:01 -0700
> 
> The attached patch fixes a bug where migrating a face spec from custom.el to use-package :custom-face
> results in a surprising behavior change: the new spec is overlaid on the default value instead of replacing it.
> This seems to have been an unintended consequence of
> https://github.com/jwiegley/use-package/issues/934.

Thanks.

I wanted to install this, but it causes failures in the tests: the 3
that you amended and the new 4th one, see the details below.  Could
you please fix that?

Also, please include the followup change for the documentation in the
next patch submittal, and also please observe our conventions for log
messages.  In particular, too long lines there are rejected by our
git-commit-hooks.  Please also mention the bug number in the commit
log message.

Here are the errors from the tests:

  Test use-package-test/:custom-face-1 backtrace:
    signal(ert-test-failed (((should (pcase (expand-minimally (use-packa
    ert-fail(((should (pcase (expand-minimally (use-package foo :custom-
    (if (unwind-protect (setq value-665 (let* ((val (let (... ...) (macr
    (let (form-description-666) (if (unwind-protect (setq value-665 (let
    (let ((value-665 (gensym "ert-form-evaluation-aborted-"))) (let (for
    #f(lambda () [t] (let ((value-665 (gensym "ert-form-evaluation-abort
    #f(compiled-function () #<bytecode -0x17069ad950ffacee>)()
    handler-bind-1(#f(compiled-function () #<bytecode -0x17069ad950fface
    ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
    ert-run-test(#s(ert-test :name use-package-test/:custom-face-1 :docu
    ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
    ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
    ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
    ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
    eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
    command-line-1(("-L" ";." "-l" "ert" "--eval" "(setq treesit-extra-l
    command-line()
    normal-top-level()
  Test use-package-test/:custom-face-1 condition:
      (ert-test-failed
       ((should (pcase (expand-minimally ...) (... t))) :form
	(let* ((val ...)) (if (equal val ...) (let nil t))) :value nil))
     FAILED   71/167  use-package-test/:custom-face-1 (0.000224 sec) at lisp/use-package/use-package-tests.el:1152
  Test use-package-test/:custom-face-2 backtrace:
    signal(ert-test-failed (((should (pcase (expand-minimally (use-packa
    ert-fail(((should (pcase (expand-minimally (use-package example :cus
    (if (unwind-protect (setq value-667 (let* ((val (let (... ...) (macr
    (let (form-description-668) (if (unwind-protect (setq value-667 (let
    (let ((value-667 (gensym "ert-form-evaluation-aborted-"))) (let (for
    #f(lambda () [t] (let ((value-667 (gensym "ert-form-evaluation-abort
    #f(compiled-function () #<bytecode -0x17069ad950ffacee>)()
    handler-bind-1(#f(compiled-function () #<bytecode -0x17069ad950fface
    ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
    ert-run-test(#s(ert-test :name use-package-test/:custom-face-2 :docu
    ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
    ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
    ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
    ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
    eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
    command-line-1(("-L" ";." "-l" "ert" "--eval" "(setq treesit-extra-l
    command-line()
    normal-top-level()
  Test use-package-test/:custom-face-2 condition:
      (ert-test-failed
       ((should (pcase (expand-minimally ...) (... t))) :form
	(let* ((val ...)) (if (equal val ...) (let nil t))) :value nil))
     FAILED   72/167  use-package-test/:custom-face-2 (0.000323 sec) at lisp/use-package/use-package-tests.el:1164
  Test use-package-test/:custom-face-3 backtrace:
    signal(ert-test-failed (((should (pcase (expand-minimally (use-packa
    ert-fail(((should (pcase (expand-minimally (use-package foo :custom-
    (if (unwind-protect (setq value-669 (let* ((val (let (... ...) (macr
    (let (form-description-670) (if (unwind-protect (setq value-669 (let
    (let ((value-669 (gensym "ert-form-evaluation-aborted-"))) (let (for
    #f(lambda () [t] (let ((value-669 (gensym "ert-form-evaluation-abort
    #f(compiled-function () #<bytecode -0x17069ad950ffacee>)()
    handler-bind-1(#f(compiled-function () #<bytecode -0x17069ad950fface
    ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
    ert-run-test(#s(ert-test :name use-package-test/:custom-face-3 :docu
    ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
    ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
    ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
    ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
    eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
    command-line-1(("-L" ";." "-l" "ert" "--eval" "(setq treesit-extra-l
    command-line()
    normal-top-level()
  Test use-package-test/:custom-face-3 condition:
      (ert-test-failed
       ((should (pcase (expand-minimally ...) (... t))) :form
	(let* ((val ...)) (if (equal val ...) (let nil t))) :value nil))
     FAILED   73/167  use-package-test/:custom-face-3 (0.000269 sec) at lisp/use-package/use-package-tests.el:1183
  Test use-package-test/:custom-face-4 backtrace:
    signal(ert-test-failed (((should (equal (face-background 'use-packag
    ert-fail(((should (equal (face-background 'use-package-test/face nil
    (if (unwind-protect (setq value-678 (apply fn-676 args-677)) (setq f
    (let (form-description-680) (if (unwind-protect (setq value-678 (app
    (let ((value-678 'ert-form-evaluation-aborted-679)) (let (form-descr
    (let* ((fn-676 #'equal) (args-677 (condition-case err (list (face-ba
    #f(lambda () [t] (custom-declare-face 'use-package-test/base-face '(
    #f(compiled-function () #<bytecode -0x17069ad950ffacee>)()
    handler-bind-1(#f(compiled-function () #<bytecode -0x17069ad950fface
    ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
    ert-run-test(#s(ert-test :name use-package-test/:custom-face-4 :docu
    ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
    ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
    ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
    ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
    eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
    command-line-1(("-L" ";." "-l" "ert" "--eval" "(setq treesit-extra-l
    command-line()
    normal-top-level()
  Test use-package-test/:custom-face-4 condition:
      (ert-test-failed
       ((should (equal (face-background ... nil t) nil)) :form
	(equal "green" nil) :value nil :explanation
	(different-types "green" nil)))
     FAILED   74/167  use-package-test/:custom-face-4 (0.000288 sec) at lisp/use-package/use-package-tests.el:1194

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

From: Michael Shields <shields <at> msrl.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, John Wiegley <johnw <at> gnu.org>
Subject: Re: bug#77928: [PATCH] use-package :custom-face is meant to behave
 like custom-set-face
Date: Sat, 26 Apr 2025 13:35:42 -0700

[Message part 1 (text/plain, inline)]

Attached is a combined patch with an updated commit message.

I cannot reproduce those test failures. I see 167/167 tests pass when I run
`make -C test check-lisp-use-package'. I'm testing commit be4819b, plus the
attached patch, on macOS 15.4.1.

[Message part 2 (text/html, inline)]

[0001-Fix-use-package-custom-face-to-set-face-defface-spec.patch (application/octet-stream, attachment)]

Message #25 received at 77928-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Shields <shields <at> msrl.com>
Cc: 77928-done <at> debbugs.gnu.org, johnw <at> gnu.org
Subject: Re: bug#77928: [PATCH] use-package :custom-face is meant to behave
 like custom-set-face
Date: Sun, 27 Apr 2025 10:50:50 +0300

> From: Michael Shields <shields <at> msrl.com>
> Date: Sat, 26 Apr 2025 13:35:42 -0700
> Cc: John Wiegley <johnw <at> gnu.org>, 77928 <at> debbugs.gnu.org
> 
> Attached is a combined patch with an updated commit message.
> 
> I cannot reproduce those test failures. I see 167/167 tests pass when I run `make -C test
> check-lisp-use-package'. I'm testing commit be4819b, plus the attached patch, on macOS 15.4.1.

Thanks, installed on the master branch, and closing the bug.

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

From: Steven Allen <steven <at> stebalien.com>
To: 77928 <at> debbugs.gnu.org
Cc: johnw <at> gnu.org, Michael Shields <shields <at> msrl.com>
Subject: [PATCH] use-package :custom-face is meant to behave like
 custom-set-face
Date: Sun, 27 Apr 2025 07:50:07 -0700

From my testing, this makes it impossible to override themed faces with
:custom-face. This can be reproduced by applying a theme then attempting
to override a themed face with :custom-face.

Additionally, this patch makes the feature much less useful for tweaking
faces. Previously, it was possible to achieve both behaviors (override or
merge), now it's only possible to override.

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

From: Steven Allen <steven <at> stebalien.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face for themed faces
Date: Wed, 30 Apr 2025 14:26:34 -0700

ebcde0f90f6 (bug#77928) makes it impossible to override themed faces with
:custom-face. This can be reproduced by:

1. Applying a theme (tested with modus).
2. Then attempt to override a themed face with ":custom-face".

E.g., put the following into a scratch buffer and eval it.

    (load-theme 'modus-vivendi)
    (use-package emacs :custom-face (font-lock-keyword-face ((t :italic t))))

I'd expect my keywords to become italic but nothing happens (tested with
`emacs -Q`).

Additionally, this patch (as it was intended, as far as I can tell)
makes the :custom-face feature much less useful for tweaking faces.
Previously, it was possible to achieve both behaviors (override or
merge), now it's only possible to override faces entirely which isn't
nearly as useful.

(I posted a comment on
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77928#28 but the bug was
already closed)


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, cairo version
 1.18.4) of 2025-04-30 built on Laptop
Repository revision: 1108523eb03d62eea10ece284594a862f0a62bcb
Repository branch: merged
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Arch Linux

Configured using:
 'configure
 'CPPFLAGS=-I/run/user/1000/build/emacs-git/src/mps-git/build/include '
 'LDFLAGS=-L/run/user/1000/build/emacs-git/src/mps-git/build/lib -Wl,-O1
 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
 -Wl,-z,pack-relative-relocs -flto=auto' --prefix=/usr --sysconfdir=/etc
 --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man
 --with-gameuser=:games --with-modules --without-m17n-flt
 --without-selinux --without-pop --without-gconf --disable-gc-mark-trace
 --with-mps=yes --enable-link-time-optimization
 --with-native-compilation=yes --with-xinput2 --with-x-toolkit=no
 --without-toolkit-scroll-bars --without-xft --without-xaw3d
 --without-gsettings --with-cairo-xcb --with-sound=no --with-tree-sitter
 --without-gpm --without-compress-install
 '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
 'CFLAGS=-march=native -mtune=native -O3 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection -fomit-frame-pointer
 -fno-math-errno -fno-trapping-math -fno-math-errno -fno-trapping-math
 -flto=auto''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBOTF
LIBSYSTEMD LIBXML2 MODULES MPS NATIVE_COMP NOTIFY INOTIFY OLDXMENU
PDUMPER PNG RSVG SECCOMP SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XDBE
XIM XINERAMA XINPUT2 XPM XRANDR ZLIB

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

Major mode: EXWM

Minor modes in effect:
  notmuch-bookmarks-mode: t
  windmove-mode: t
  global-atomic-chrome-edit-mode: t
  iwd-agent-mode: t
  i3bar-mode: t
  ednc-mode: t
  exwm-xsettings-mode: t
  exwm-background-mode: t
  exwm-systemtray-mode: t
  exwm-randr-mode: t
  compile-angel-on-load-mode: t
  save-place-mode: t
  savehist-mode: t
  global-org-modern-mode: t
  eat-eshell-mode: t
  magit-todos-mode: t
  global-git-commit-mode: t
  server-mode: t
  llama-fontify-mode: t
  dired-async-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  ultra-scroll-mode: t
  pixel-scroll-precision-mode: t
  global-hl-todo-mode: t
  marginalia-mode: t
  nerd-icons-completion-mode: t
  global-jinx-mode: t
  visual-replace-global-mode: t
  vertico-mode: t
  corfu-popupinfo-mode: t
  global-corfu-mode: t
  corfu-mode: t
  isearch-mb-mode: t
  evil-goggles-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  global-evil-collection-unimpaired-mode: t
  evil-collection-unimpaired-mode: t
  recentf-mode: t
  editorconfig-mode: t
  global-auto-revert-mode: t
  minibuffer-depth-indicate-mode: t
  minibuffer-electric-default-mode: t
  evil-mode: t
  desktop-environment-mode: t
  elpaca-use-package-mode: t
  override-global-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-history-mode: t
  tab-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  window-divider-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/steb/.config/emacs/elpaca/builds/package-lint-flymake/package-lint-flymake hides /home/steb/.config/emacs/elpaca/builds/package-lint/package-lint-flymake
/home/steb/.config/emacs/elpaca/builds/transient/transient hides /usr/share/emacs/31.0.50/lisp/transient
/home/steb/.config/emacs/elpaca/builds/org/ox hides /usr/share/emacs/31.0.50/lisp/org/ox
/home/steb/.config/emacs/elpaca/builds/org/ox-texinfo hides /usr/share/emacs/31.0.50/lisp/org/ox-texinfo
/home/steb/.config/emacs/elpaca/builds/org/ox-publish hides /usr/share/emacs/31.0.50/lisp/org/ox-publish
/home/steb/.config/emacs/elpaca/builds/org/ox-org hides /usr/share/emacs/31.0.50/lisp/org/ox-org
/home/steb/.config/emacs/elpaca/builds/org/ox-odt hides /usr/share/emacs/31.0.50/lisp/org/ox-odt
/home/steb/.config/emacs/elpaca/builds/org/ox-md hides /usr/share/emacs/31.0.50/lisp/org/ox-md
/home/steb/.config/emacs/elpaca/builds/org/ox-man hides /usr/share/emacs/31.0.50/lisp/org/ox-man
/home/steb/.config/emacs/elpaca/builds/org/ox-latex hides /usr/share/emacs/31.0.50/lisp/org/ox-latex
/home/steb/.config/emacs/elpaca/builds/org/ox-koma-letter hides /usr/share/emacs/31.0.50/lisp/org/ox-koma-letter
/home/steb/.config/emacs/elpaca/builds/org/ox-icalendar hides /usr/share/emacs/31.0.50/lisp/org/ox-icalendar
/home/steb/.config/emacs/elpaca/builds/org/ox-html hides /usr/share/emacs/31.0.50/lisp/org/ox-html
/home/steb/.config/emacs/elpaca/builds/org/ox-beamer hides /usr/share/emacs/31.0.50/lisp/org/ox-beamer
/home/steb/.config/emacs/elpaca/builds/org/ox-ascii hides /usr/share/emacs/31.0.50/lisp/org/ox-ascii
/home/steb/.config/emacs/elpaca/builds/org/org hides /usr/share/emacs/31.0.50/lisp/org/org
/home/steb/.config/emacs/elpaca/builds/org/org-version hides /usr/share/emacs/31.0.50/lisp/org/org-version
/home/steb/.config/emacs/elpaca/builds/org/org-timer hides /usr/share/emacs/31.0.50/lisp/org/org-timer
/home/steb/.config/emacs/elpaca/builds/org/org-tempo hides /usr/share/emacs/31.0.50/lisp/org/org-tempo
/home/steb/.config/emacs/elpaca/builds/org/org-table hides /usr/share/emacs/31.0.50/lisp/org/org-table
/home/steb/.config/emacs/elpaca/builds/org/org-src hides /usr/share/emacs/31.0.50/lisp/org/org-src
/home/steb/.config/emacs/elpaca/builds/org/org-refile hides /usr/share/emacs/31.0.50/lisp/org/org-refile
/home/steb/.config/emacs/elpaca/builds/org/org-protocol hides /usr/share/emacs/31.0.50/lisp/org/org-protocol
/home/steb/.config/emacs/elpaca/builds/org/org-plot hides /usr/share/emacs/31.0.50/lisp/org/org-plot
/home/steb/.config/emacs/elpaca/builds/org/org-persist hides /usr/share/emacs/31.0.50/lisp/org/org-persist
/home/steb/.config/emacs/elpaca/builds/org/org-pcomplete hides /usr/share/emacs/31.0.50/lisp/org/org-pcomplete
/home/steb/.config/emacs/elpaca/builds/org/org-num hides /usr/share/emacs/31.0.50/lisp/org/org-num
/home/steb/.config/emacs/elpaca/builds/org/org-mouse hides /usr/share/emacs/31.0.50/lisp/org/org-mouse
/home/steb/.config/emacs/elpaca/builds/org/org-mobile hides /usr/share/emacs/31.0.50/lisp/org/org-mobile
/home/steb/.config/emacs/elpaca/builds/org/org-macs hides /usr/share/emacs/31.0.50/lisp/org/org-macs
/home/steb/.config/emacs/elpaca/builds/org/org-macro hides /usr/share/emacs/31.0.50/lisp/org/org-macro
/home/steb/.config/emacs/elpaca/builds/org/org-loaddefs hides /usr/share/emacs/31.0.50/lisp/org/org-loaddefs
/home/steb/.config/emacs/elpaca/builds/org/org-list hides /usr/share/emacs/31.0.50/lisp/org/org-list
/home/steb/.config/emacs/elpaca/builds/org/org-lint hides /usr/share/emacs/31.0.50/lisp/org/org-lint
/home/steb/.config/emacs/elpaca/builds/org/org-keys hides /usr/share/emacs/31.0.50/lisp/org/org-keys
/home/steb/.config/emacs/elpaca/builds/org/org-inlinetask hides /usr/share/emacs/31.0.50/lisp/org/org-inlinetask
/home/steb/.config/emacs/elpaca/builds/org/org-indent hides /usr/share/emacs/31.0.50/lisp/org/org-indent
/home/steb/.config/emacs/elpaca/builds/org/org-id hides /usr/share/emacs/31.0.50/lisp/org/org-id
/home/steb/.config/emacs/elpaca/builds/org/org-habit hides /usr/share/emacs/31.0.50/lisp/org/org-habit
/home/steb/.config/emacs/elpaca/builds/org/org-goto hides /usr/share/emacs/31.0.50/lisp/org/org-goto
/home/steb/.config/emacs/elpaca/builds/org/org-footnote hides /usr/share/emacs/31.0.50/lisp/org/org-footnote
/home/steb/.config/emacs/elpaca/builds/org/org-fold hides /usr/share/emacs/31.0.50/lisp/org/org-fold
/home/steb/.config/emacs/elpaca/builds/org/org-fold-core hides /usr/share/emacs/31.0.50/lisp/org/org-fold-core
/home/steb/.config/emacs/elpaca/builds/org/org-feed hides /usr/share/emacs/31.0.50/lisp/org/org-feed
/home/steb/.config/emacs/elpaca/builds/org/org-faces hides /usr/share/emacs/31.0.50/lisp/org/org-faces
/home/steb/.config/emacs/elpaca/builds/org/org-entities hides /usr/share/emacs/31.0.50/lisp/org/org-entities
/home/steb/.config/emacs/elpaca/builds/org/org-element hides /usr/share/emacs/31.0.50/lisp/org/org-element
/home/steb/.config/emacs/elpaca/builds/org/org-element-ast hides /usr/share/emacs/31.0.50/lisp/org/org-element-ast
/home/steb/.config/emacs/elpaca/builds/org/org-duration hides /usr/share/emacs/31.0.50/lisp/org/org-duration
/home/steb/.config/emacs/elpaca/builds/org/org-datetree hides /usr/share/emacs/31.0.50/lisp/org/org-datetree
/home/steb/.config/emacs/elpaca/builds/org/org-cycle hides /usr/share/emacs/31.0.50/lisp/org/org-cycle
/home/steb/.config/emacs/elpaca/builds/org/org-ctags hides /usr/share/emacs/31.0.50/lisp/org/org-ctags
/home/steb/.config/emacs/elpaca/builds/org/org-crypt hides /usr/share/emacs/31.0.50/lisp/org/org-crypt
/home/steb/.config/emacs/elpaca/builds/org/org-compat hides /usr/share/emacs/31.0.50/lisp/org/org-compat
/home/steb/.config/emacs/elpaca/builds/org/org-colview hides /usr/share/emacs/31.0.50/lisp/org/org-colview
/home/steb/.config/emacs/elpaca/builds/org/org-clock hides /usr/share/emacs/31.0.50/lisp/org/org-clock
/home/steb/.config/emacs/elpaca/builds/org/org-capture hides /usr/share/emacs/31.0.50/lisp/org/org-capture
/home/steb/.config/emacs/elpaca/builds/org/org-attach hides /usr/share/emacs/31.0.50/lisp/org/org-attach
/home/steb/.config/emacs/elpaca/builds/org/org-attach-git hides /usr/share/emacs/31.0.50/lisp/org/org-attach-git
/home/steb/.config/emacs/elpaca/builds/org/org-archive hides /usr/share/emacs/31.0.50/lisp/org/org-archive
/home/steb/.config/emacs/elpaca/builds/org/org-agenda hides /usr/share/emacs/31.0.50/lisp/org/org-agenda
/home/steb/.config/emacs/elpaca/builds/org/ol hides /usr/share/emacs/31.0.50/lisp/org/ol
/home/steb/.config/emacs/elpaca/builds/org/ol-w3m hides /usr/share/emacs/31.0.50/lisp/org/ol-w3m
/home/steb/.config/emacs/elpaca/builds/org/ol-rmail hides /usr/share/emacs/31.0.50/lisp/org/ol-rmail
/home/steb/.config/emacs/elpaca/builds/org/ol-mhe hides /usr/share/emacs/31.0.50/lisp/org/ol-mhe
/home/steb/.config/emacs/elpaca/builds/org/ol-man hides /usr/share/emacs/31.0.50/lisp/org/ol-man
/home/steb/.config/emacs/elpaca/builds/org/ol-irc hides /usr/share/emacs/31.0.50/lisp/org/ol-irc
/home/steb/.config/emacs/elpaca/builds/org/ol-info hides /usr/share/emacs/31.0.50/lisp/org/ol-info
/home/steb/.config/emacs/elpaca/builds/org/ol-gnus hides /usr/share/emacs/31.0.50/lisp/org/ol-gnus
/home/steb/.config/emacs/elpaca/builds/org/ol-eww hides /usr/share/emacs/31.0.50/lisp/org/ol-eww
/home/steb/.config/emacs/elpaca/builds/org/ol-eshell hides /usr/share/emacs/31.0.50/lisp/org/ol-eshell
/home/steb/.config/emacs/elpaca/builds/org/ol-doi hides /usr/share/emacs/31.0.50/lisp/org/ol-doi
/home/steb/.config/emacs/elpaca/builds/org/ol-docview hides /usr/share/emacs/31.0.50/lisp/org/ol-docview
/home/steb/.config/emacs/elpaca/builds/org/ol-bibtex hides /usr/share/emacs/31.0.50/lisp/org/ol-bibtex
/home/steb/.config/emacs/elpaca/builds/org/ol-bbdb hides /usr/share/emacs/31.0.50/lisp/org/ol-bbdb
/home/steb/.config/emacs/elpaca/builds/org/oc hides /usr/share/emacs/31.0.50/lisp/org/oc
/home/steb/.config/emacs/elpaca/builds/org/oc-natbib hides /usr/share/emacs/31.0.50/lisp/org/oc-natbib
/home/steb/.config/emacs/elpaca/builds/org/oc-csl hides /usr/share/emacs/31.0.50/lisp/org/oc-csl
/home/steb/.config/emacs/elpaca/builds/org/oc-bibtex hides /usr/share/emacs/31.0.50/lisp/org/oc-bibtex
/home/steb/.config/emacs/elpaca/builds/org/oc-biblatex hides /usr/share/emacs/31.0.50/lisp/org/oc-biblatex
/home/steb/.config/emacs/elpaca/builds/org/oc-basic hides /usr/share/emacs/31.0.50/lisp/org/oc-basic
/home/steb/.config/emacs/elpaca/builds/org/ob hides /usr/share/emacs/31.0.50/lisp/org/ob
/home/steb/.config/emacs/elpaca/builds/org/ob-tangle hides /usr/share/emacs/31.0.50/lisp/org/ob-tangle
/home/steb/.config/emacs/elpaca/builds/org/ob-table hides /usr/share/emacs/31.0.50/lisp/org/ob-table
/home/steb/.config/emacs/elpaca/builds/org/ob-sqlite hides /usr/share/emacs/31.0.50/lisp/org/ob-sqlite
/home/steb/.config/emacs/elpaca/builds/org/ob-sql hides /usr/share/emacs/31.0.50/lisp/org/ob-sql
/home/steb/.config/emacs/elpaca/builds/org/ob-shell hides /usr/share/emacs/31.0.50/lisp/org/ob-shell
/home/steb/.config/emacs/elpaca/builds/org/ob-sed hides /usr/share/emacs/31.0.50/lisp/org/ob-sed
/home/steb/.config/emacs/elpaca/builds/org/ob-screen hides /usr/share/emacs/31.0.50/lisp/org/ob-screen
/home/steb/.config/emacs/elpaca/builds/org/ob-scheme hides /usr/share/emacs/31.0.50/lisp/org/ob-scheme
/home/steb/.config/emacs/elpaca/builds/org/ob-sass hides /usr/share/emacs/31.0.50/lisp/org/ob-sass
/home/steb/.config/emacs/elpaca/builds/org/ob-ruby hides /usr/share/emacs/31.0.50/lisp/org/ob-ruby
/home/steb/.config/emacs/elpaca/builds/org/ob-ref hides /usr/share/emacs/31.0.50/lisp/org/ob-ref
/home/steb/.config/emacs/elpaca/builds/org/ob-python hides /usr/share/emacs/31.0.50/lisp/org/ob-python
/home/steb/.config/emacs/elpaca/builds/org/ob-processing hides /usr/share/emacs/31.0.50/lisp/org/ob-processing
/home/steb/.config/emacs/elpaca/builds/org/ob-plantuml hides /usr/share/emacs/31.0.50/lisp/org/ob-plantuml
/home/steb/.config/emacs/elpaca/builds/org/ob-perl hides /usr/share/emacs/31.0.50/lisp/org/ob-perl
/home/steb/.config/emacs/elpaca/builds/org/ob-org hides /usr/share/emacs/31.0.50/lisp/org/ob-org
/home/steb/.config/emacs/elpaca/builds/org/ob-octave hides /usr/share/emacs/31.0.50/lisp/org/ob-octave
/home/steb/.config/emacs/elpaca/builds/org/ob-ocaml hides /usr/share/emacs/31.0.50/lisp/org/ob-ocaml
/home/steb/.config/emacs/elpaca/builds/org/ob-maxima hides /usr/share/emacs/31.0.50/lisp/org/ob-maxima
/home/steb/.config/emacs/elpaca/builds/org/ob-matlab hides /usr/share/emacs/31.0.50/lisp/org/ob-matlab
/home/steb/.config/emacs/elpaca/builds/org/ob-makefile hides /usr/share/emacs/31.0.50/lisp/org/ob-makefile
/home/steb/.config/emacs/elpaca/builds/org/ob-lua hides /usr/share/emacs/31.0.50/lisp/org/ob-lua
/home/steb/.config/emacs/elpaca/builds/org/ob-lob hides /usr/share/emacs/31.0.50/lisp/org/ob-lob
/home/steb/.config/emacs/elpaca/builds/org/ob-lisp hides /usr/share/emacs/31.0.50/lisp/org/ob-lisp
/home/steb/.config/emacs/elpaca/builds/org/ob-lilypond hides /usr/share/emacs/31.0.50/lisp/org/ob-lilypond
/home/steb/.config/emacs/elpaca/builds/org/ob-latex hides /usr/share/emacs/31.0.50/lisp/org/ob-latex
/home/steb/.config/emacs/elpaca/builds/org/ob-julia hides /usr/share/emacs/31.0.50/lisp/org/ob-julia
/home/steb/.config/emacs/elpaca/builds/org/ob-js hides /usr/share/emacs/31.0.50/lisp/org/ob-js
/home/steb/.config/emacs/elpaca/builds/org/ob-java hides /usr/share/emacs/31.0.50/lisp/org/ob-java
/home/steb/.config/emacs/elpaca/builds/org/ob-haskell hides /usr/share/emacs/31.0.50/lisp/org/ob-haskell
/home/steb/.config/emacs/elpaca/builds/org/ob-groovy hides /usr/share/emacs/31.0.50/lisp/org/ob-groovy
/home/steb/.config/emacs/elpaca/builds/org/ob-gnuplot hides /usr/share/emacs/31.0.50/lisp/org/ob-gnuplot
/home/steb/.config/emacs/elpaca/builds/org/ob-fortran hides /usr/share/emacs/31.0.50/lisp/org/ob-fortran
/home/steb/.config/emacs/elpaca/builds/org/ob-forth hides /usr/share/emacs/31.0.50/lisp/org/ob-forth
/home/steb/.config/emacs/elpaca/builds/org/ob-exp hides /usr/share/emacs/31.0.50/lisp/org/ob-exp
/home/steb/.config/emacs/elpaca/builds/org/ob-eval hides /usr/share/emacs/31.0.50/lisp/org/ob-eval
/home/steb/.config/emacs/elpaca/builds/org/ob-eshell hides /usr/share/emacs/31.0.50/lisp/org/ob-eshell
/home/steb/.config/emacs/elpaca/builds/org/ob-emacs-lisp hides /usr/share/emacs/31.0.50/lisp/org/ob-emacs-lisp
/home/steb/.config/emacs/elpaca/builds/org/ob-dot hides /usr/share/emacs/31.0.50/lisp/org/ob-dot
/home/steb/.config/emacs/elpaca/builds/org/ob-ditaa hides /usr/share/emacs/31.0.50/lisp/org/ob-ditaa
/home/steb/.config/emacs/elpaca/builds/org/ob-css hides /usr/share/emacs/31.0.50/lisp/org/ob-css
/home/steb/.config/emacs/elpaca/builds/org/ob-core hides /usr/share/emacs/31.0.50/lisp/org/ob-core
/home/steb/.config/emacs/elpaca/builds/org/ob-comint hides /usr/share/emacs/31.0.50/lisp/org/ob-comint
/home/steb/.config/emacs/elpaca/builds/org/ob-clojure hides /usr/share/emacs/31.0.50/lisp/org/ob-clojure
/home/steb/.config/emacs/elpaca/builds/org/ob-calc hides /usr/share/emacs/31.0.50/lisp/org/ob-calc
/home/steb/.config/emacs/elpaca/builds/org/ob-awk hides /usr/share/emacs/31.0.50/lisp/org/ob-awk
/home/steb/.config/emacs/elpaca/builds/org/ob-R hides /usr/share/emacs/31.0.50/lisp/org/ob-R
/home/steb/.config/emacs/elpaca/builds/org/ob-C hides /usr/share/emacs/31.0.50/lisp/org/ob-C

Features:
(shadow sort mail-extr hippie-exp misearch multi-isearch
emacsql-sqlite-builtin eshell-syntax-highlighting em-elecslash em-ls
em-glob em-extpipe em-dirs em-basic em-alias emacsbug lisp-mnt help-fns
radix-tree mule-util vertico-sort tramp-cmds rainbow-mode
evil-collection-flymake flymake rainbow-delimiters
evil-collection-vc-git vc-git vc-dispatcher vertico-repeat
evil-collection-consult consult magit-bookmark org-bookmark-heading
notmuch-bookmarks evil-collection-bookmark bookmark windmove tramp-cache
time-stamp filechooser pinentry evil-collection-atomic-chrome
atomic-chrome websocket bindat iwd i3bar ednc dbus xml exwm-xsettings
xcb-xsettings exwm-background exwm-systemtray xcb-systemtray xcb-xembed
exwm-randr xcb-randr exwm exwm-input xcb-keysyms xcb-xkb exwm-manage
exwm-floating xcb-cursor xcb-render exwm-layout exwm-workspace exwm-core
xcb-ewmh xcb-icccm xcb xcb-xproto xcb-types xcb-debug posframe
face-remap visual-fill-column ligature cape org-appear stripspace
oc-basic bibtex ol-man ol-info ol-docview evil-collection-doc-view
doc-view jka-compr evil-collection-image image-mode exif compile-angel
saveplace savehist show-font org-protocol evil-org org-element
org-persist org-id org-refile avl-tree org-modern ob-dot ob-latex
ob-python evil-collection-python python ob-gnuplot ob-calc calc-store
calc-trail calc-ext evil-collection-calc calc calc-loaddefs calc-macs
ob-shell evil-collection-org org-crypt org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-src evil-collection-sh-script sh-script
smie executable ob-comint org-element-ast inline org-pcomplete org-list
org-footnote org-faces org-entities ob-emacs-lisp ob-core ob-eval
org-cycle org-table ol org-fold org-fold-core org-keys oc org-compat
org-version org-macs notmuch-addr evil-collection-eat eat term/xterm
xterm tramp-sh tramp trampver tramp-integration tramp-message
tramp-compat tramp-loaddefs evil-collection-term term ehelp
evil-collection-forge forge-repos forge-tablist forge-topics
forge-commands forge-semi forge-bitbucket buck forge-gogs gogs
forge-gitea gtea forge-gitlab glab forge-github ghub-graphql treepy
gsexp ghub url-http url-gw nsm url-auth let-alist forge-forgejo
forge-notify forge-revnote forge-pullreq forge-issue forge-discussion
forge-topic yaml parse-time iso8601 eieio-custom bug-reference
forge-post evil-collection-markdown-mode markdown-mode edit-indirect
evil-collection-outline noutline outline forge-repo forge forge-core
forge-db closql emacsql-sqlite emacsql emacsql-compiler eieio-base
evil-collection-magit-todos magit-todos pcre2el rxt advice re-builder f
s dash evil-collection-grep grep evil-collection-compile compile
evil-collection-magit magit-submodule magit-blame magit-stash
magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-files magit-refs
magit-status magit evil-collection-package-menu package url-handlers
evil-collection-magit-repos magit-repos magit-apply magit-wip magit-log
which-func evil-collection-imenu imenu magit-diff
evil-collection-smerge-mode smerge-mode diff git-commit
evil-collection-log-edit log-edit pcvs-util add-log magit-core
magit-autorevert magit-margin magit-transient magit-process
evil-collection-with-editor with-editor shell server magit-mode
transient browse-url benchmark magit-git magit-base
evil-collection-magit-section magit-section cursor-sensor llama
dired-async async dired-aux yasnippet evil-collection-ultra-scroll
ultra-scroll pixel-scroll cua-base hl-todo marginalia nerd-icons-corfu
nerd-icons-completion nerd-icons nerd-icons-faces nerd-icons-data
nerd-icons-data-mdicon nerd-icons-data-flicon nerd-icons-data-codicon
nerd-icons-data-devicon nerd-icons-data-sucicon nerd-icons-data-wicon
nerd-icons-data-faicon nerd-icons-data-powerline nerd-icons-data-octicon
nerd-icons-data-pomicon nerd-icons-data-ipsicon jinx visual-replace
evil-collection-which-key which-key vertico corfu-popupinfo
evil-collection-corfu corfu orderless isearch-mb evil-goggles pulse
color evil-textobj-tree-sitter evil-textobj-tree-sitter-thing-at-point
evil-textobj-tree-sitter-core treesit evil-args evil-surround cus-start
evil-collection-unimpaired evil-collection-tabulated-list
evil-collection-tab-bar evil-collection-simple evil-collection-replace
evil-collection-process-menu evil-collection-notmuch
evil-collection-kmacro evil-collection-indent evil-collection-help
evil-collection-epa evil-collection-elisp-mode evil-collection-eldoc
evil-collection-elpaca evil-collection-dired evil-collection-custom
evil-collection-comint evil-collection-calendar
evil-collection-buff-menu evil-collection annalist ednc-autoloads
i3bar-autoloads discomfort-autoloads debase-autoloads iwd-autoloads
bluetooth-autoloads app-launcher-autoloads atomic-chrome-autoloads
websocket-autoloads pinentry-autoloads playerctl-autoloads
exwm-autoloads xelb-autoloads ol-notmuch-autoloads microdata-autoloads
notmuch-addr-autoloads eshell-syntax-highlighting-autoloads
eat-autoloads git-link-autoloads pr-review-autoloads igist-autoloads
magit-todos-autoloads wgrep-autoloads watch-autoloads tmr-autoloads
syncthing-autoloads pcre2el-autoloads qrencode-autoloads
password-store-menu-autoloads password-store-autoloads
named-pipe-autoloads info-colors-autoloads helpful-autoloads
elisp-refs-autoloads devdocs-autoloads whisper-autoloads gptel-autoloads
copilot-autoloads tzc-autoloads journalctl-autoloads systemctl-autoloads
proced-narrow-autoloads show-font-autoloads dbus-explore-autoloads
disk-usage-autoloads dired-filter-autoloads dired-hacks-utils-autoloads
f-autoloads s-autoloads dash-autoloads diredfl-autoloads
org-bookmark-heading-autoloads notmuch-bookmarks-autoloads
pdf-tools-autoloads tablist-autoloads nov-autoloads esxml-autoloads
calibre-autoloads orgit-forge-autoloads forge-autoloads closql-autoloads
emacsql-autoloads ghub-autoloads treepy-autoloads yaml-autoloads
orgit-autoloads magit-autoloads magit-section-autoloads
with-editor-autoloads evil-org-autoloads org-download-autoloads
async-autoloads org-appear-autoloads org-modern-autoloads org-loaddefs
edit-indirect-autoloads markdown-mode-autoloads web-mode-autoloads
wat-ts-mode-autoloads solidity-mode-autoloads comint-mime-autoloads
mathjax-autoloads flymake-ruff-autoloads evm-mode-autoloads
package-lint-flymake-autoloads package-lint-autoloads eff-autoloads
pkgbuild-mode-autoloads gnuplot-autoloads graphviz-dot-mode-autoloads
csv-mode-autoloads udev-mode-autoloads systemd-autoloads
ssh-config-mode-autoloads nftables-mode-autoloads git-modes-autoloads
rmsbolt-autoloads rust-playground-autoloads consult-eglot-autoloads
dape-autoloads casual-autoloads notmuch-transient-autoloads
transient-autoloads bash-completion-autoloads cape-autoloads
yasnippet-autoloads iwindow-autoloads consult-project-extra-autoloads
ultra-scroll-autoloads ligature-autoloads hl-todo-autoloads
rainbow-mode-autoloads marginalia-autoloads posframe-autoloads
rainbow-delimiters-autoloads visual-fill-column-autoloads
nerd-icons-corfu-autoloads nerd-icons-ibuffer-autoloads
nerd-icons-completion-autoloads nerd-icons-dired-autoloads
nerd-icons-autoloads link-hint-autoloads avy-autoloads
snapshot-timemachine-autoloads stripspace-autoloads vundo-autoloads
jinx-autoloads visual-replace-autoloads vertico-autoloads
corfu-autoloads orderless-autoloads isearch-mb-autoloads
embark-consult-autoloads consult-autoloads embark-autoloads
evil-goggles-autoloads evil-nerd-commenter-autoloads
evil-textobj-tree-sitter-autoloads evil-args-autoloads
evil-surround-autoloads evil-collection-autoloads annalist-autoloads
filechooser-autoloads 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 format-spec notmuch-wash diff-mode track-changes coolj
goto-addr icalendar diary-lib diary-loaddefs cal-menu calendar
cal-loaddefs notmuch-tag crm notmuch-lib notmuch-compat hl-line message
sendmail yank-media dired dired-loaddefs rfc822 mml mailabbrev
mail-utils gmm-utils mailheader mm-view mml-smime mml-sec epa epg
rfc6068 epg-config gnus-util time-date smime gnutls puny dig mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr em-prompt text-property-search em-hist em-unix
em-pred esh-mode esh-var eshell esh-cmd generator esh-ext esh-proc
esh-opt esh-io esh-arg pcomplete comint ansi-osc ansi-color esh-module
esh-module-loaddefs esh-util files-x recentf tree-widget editorconfig
editorconfig-core editorconfig-core-handle editorconfig-fnmatch project
disp-table modus-operandi-theme modus-themes derived pcase autorevert
filenotify mb-depth minibuf-eldef elpaca-menu-elpa evil evil-integration
evil-maps evil-commands reveal evil-jumps evil-command-window evil-types
evil-search evil-ex evil-macros evil-repeat evil-states evil-core
comp-run evil-common thingatpt rect evil-vars ring edmacro kmacro
evil-autoloads goto-chg-autoloads general general-autoloads
llama-autoloads compile-angel-autoloads mode-local find-func
no-littering compat no-littering-autoloads elpaca-menu-melpa
elpaca-menu-org elpaca-use-package use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core elpaca-use-package-autoloads elpaca-log
elpaca-ui url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util url-parse auth-source
eieio eieio-core cl-macs password-cache json map byte-opt url-vars
mailcap elpaca elpaca-process elpaca-autoloads notmuch-version comp
cl-seq comp-cstr cl-extra help-mode comp-common warnings subr-x rx gv
bytecomp byte-compile xdg cus-edit pp cus-load icons wid-edit
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 touch-screen 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 font-render-setting cairo xinput2 x multi-tty
move-toolbar make-network-process tty-child-frames native-compile mps
emacs)

Memory information:
((conses 24 0 0) (symbols 56 0 0) (strings 40 0 0) (string-bytes 1 0) (vectors 24 0)
 (vector-slots 8 0 0) (floats 24 0 0) (intervals 64 0 0) (buffers 1000 0))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>, Michael Shields <shields <at> msrl.com>
Cc: 77928 <at> debbugs.gnu.org
Subject: Re: bug#77928: 31.0.50;
 ebcde0f90f6 (bug#77928) breaks :custom-face for themed faces
Date: Thu, 01 May 2025 20:43:28 +0300

> Date: Wed, 30 Apr 2025 14:26:34 -0700
> From:  Steven Allen via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 
> ebcde0f90f6 (bug#77928) makes it impossible to override themed faces with
> :custom-face. This can be reproduced by:
> 
> 1. Applying a theme (tested with modus).
> 2. Then attempt to override a themed face with ":custom-face".
> 
> E.g., put the following into a scratch buffer and eval it.
> 
>     (load-theme 'modus-vivendi)
>     (use-package emacs :custom-face (font-lock-keyword-face ((t :italic t))))
> 
> I'd expect my keywords to become italic but nothing happens (tested with
> `emacs -Q`).
> 
> Additionally, this patch (as it was intended, as far as I can tell)
> makes the :custom-face feature much less useful for tweaking faces.
> Previously, it was possible to achieve both behaviors (override or
> merge), now it's only possible to override faces entirely which isn't
> nearly as useful.
> 
> (I posted a comment on
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77928#28 but the bug was
> already closed)

Thanks.

Michael, could you please look into this regression?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: steven <at> stebalien.com, shields <at> msrl.com
Cc: 77928 <at> debbugs.gnu.org
Subject: Re: bug#77928: 31.0.50;
 ebcde0f90f6 (bug#77928) breaks :custom-face for themed faces
Date: Sat, 17 May 2025 11:02:25 +0300

Ping!  Michael, could you please chime in?

> Cc: 77928 <at> debbugs.gnu.org
> Date: Thu, 01 May 2025 20:43:28 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Date: Wed, 30 Apr 2025 14:26:34 -0700
> > From:  Steven Allen via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> > 
> > 
> > ebcde0f90f6 (bug#77928) makes it impossible to override themed faces with
> > :custom-face. This can be reproduced by:
> > 
> > 1. Applying a theme (tested with modus).
> > 2. Then attempt to override a themed face with ":custom-face".
> > 
> > E.g., put the following into a scratch buffer and eval it.
> > 
> >     (load-theme 'modus-vivendi)
> >     (use-package emacs :custom-face (font-lock-keyword-face ((t :italic t))))
> > 
> > I'd expect my keywords to become italic but nothing happens (tested with
> > `emacs -Q`).
> > 
> > Additionally, this patch (as it was intended, as far as I can tell)
> > makes the :custom-face feature much less useful for tweaking faces.
> > Previously, it was possible to achieve both behaviors (override or
> > merge), now it's only possible to override faces entirely which isn't
> > nearly as useful.
> > 
> > (I posted a comment on
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77928#28 but the bug was
> > already closed)
> 
> Thanks.
> 
> Michael, could you please look into this regression?
> 
> 
> 
> 

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

From: Michael Shields <shields <at> msrl.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, steven <at> stebalien.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sat, 17 May 2025 17:39:04 -0700

[Message part 1 (text/plain, inline)]

I can take a look at this tomorrow.

On Sat, May 17, 2025 at 1:02 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> Ping!  Michael, could you please chime in?
>
> > Cc: 77928 <at> debbugs.gnu.org
> > Date: Thu, 01 May 2025 20:43:28 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> >
> > > Date: Wed, 30 Apr 2025 14:26:34 -0700
> > > From:  Steven Allen via "Bug reports for GNU Emacs,
> > >  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> > >
> > >
> > > ebcde0f90f6 (bug#77928) makes it impossible to override themed faces
> with
> > > :custom-face. This can be reproduced by:
> > >
> > > 1. Applying a theme (tested with modus).
> > > 2. Then attempt to override a themed face with ":custom-face".
> > >
> > > E.g., put the following into a scratch buffer and eval it.
> > >
> > >     (load-theme 'modus-vivendi)
> > >     (use-package emacs :custom-face (font-lock-keyword-face ((t
> :italic t))))
> > >
> > > I'd expect my keywords to become italic but nothing happens (tested
> with
> > > `emacs -Q`).
> > >
> > > Additionally, this patch (as it was intended, as far as I can tell)
> > > makes the :custom-face feature much less useful for tweaking faces.
> > > Previously, it was possible to achieve both behaviors (override or
> > > merge), now it's only possible to override faces entirely which isn't
> > > nearly as useful.
> > >
> > > (I posted a comment on
> > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77928#28 but the bug was
> > > already closed)
> >
> > Thanks.
> >
> > Michael, could you please look into this regression?
> >
> >
> >
> >
>

[Message part 2 (text/html, inline)]

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

From: Michael Shields <shields <at> msrl.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, steven <at> stebalien.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Mon, 19 May 2025 22:51:29 -0700

[Message part 1 (text/plain, inline)]

I think I understand the issue, but not its solution. There are more or
less three standard ways to change faces now: Customize, themes, and
use-package :custom-face. But there is no clear way to resolve the ordering
between them, or whether they replace or inherit at each level. The
behavior I was surprised by, and that has been reported previously, is that
there was no way to specify a replacement for face settings. But Steven is
surprised by the fact that things now happen at a level below theme
application, and the theme replaces instead of inherits the defface spec.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Shields <shields <at> msrl.com>, John Wiegley <johnw <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, steven <at> stebalien.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sat, 24 May 2025 12:30:17 +0300

> From: Michael Shields <shields <at> msrl.com>
> Date: Mon, 19 May 2025 22:51:29 -0700
> Cc: steven <at> stebalien.com, 77928 <at> debbugs.gnu.org
> 
> I think I understand the issue, but not its solution. There are more or less three standard ways to change
> faces now: Customize, themes, and use-package :custom-face. But there is no clear way to resolve the
> ordering between them, or whether they replace or inherit at each level. The behavior I was surprised by,
> and that has been reported previously, is that there was no way to specify a replacement for face settings.
> But Steven is surprised by the fact that things now happen at a level below theme application, and the theme
> replaces instead of inherits the defface spec.

John, could you perhaps help us out here?  Bug#77928 was about
:custom-face, which is a use-package feature.  I don't really
understand how this feature is supposed to work, given that
use-package produces macros whose effect happens when a package is
loaded, and given that other methods of face definition are available.

It seems like the original patch installed in this bug fixed one
(mis)behavior but introduced another.  The documentation of
:custom-face in the use-package manual is completely silent regarding
its interaction with themes and defface's.  Could you perhaps explain
the intent of this feature, and what should users expect in the two
use cases described in this bug?

Thanks.

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

From: John Wiegley <johnw <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, Michael Shields <shields <at> msrl.com>,
 steven <at> stebalien.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Mon, 26 May 2025 16:03:51 -0700

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Michael Shields <shields <at> msrl.com>
>> Date: Mon, 19 May 2025 22:51:29 -0700
>> Cc: steven <at> stebalien.com, 77928 <at> debbugs.gnu.org
>> 
>> I think I understand the issue, but not its solution. There are more or less three standard ways to change
>> faces now: Customize, themes, and use-package :custom-face. But there is no clear way to resolve the
>> ordering between them, or whether they replace or inherit at each level. The behavior I was surprised by,
>> and that has been reported previously, is that there was no way to specify a replacement for face settings.
>> But Steven is surprised by the fact that things now happen at a level below theme application, and the theme
>> replaces instead of inherits the defface spec.

> John, could you perhaps help us out here?  Bug#77928 was about
> :custom-face, which is a use-package feature.  I don't really
> understand how this feature is supposed to work, given that
> use-package produces macros whose effect happens when a package is
> loaded, and given that other methods of face definition are available.

All that use-package is doing here is expanding the ‘:custom-face‘ declaration
into this call:

  (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))

Should it be calling something other than `face-spec-set' now?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Steven Allen <steven <at> stebalien.com>
To: John Wiegley <johnw <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, Michael Shields <shields <at> msrl.com>
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Mon, 26 May 2025 18:26:24 -0700

John Wiegley <johnw <at> gnu.org> writes:

>>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Michael Shields <shields <at> msrl.com>
>>> Date: Mon, 19 May 2025 22:51:29 -0700
>>> Cc: steven <at> stebalien.com, 77928 <at> debbugs.gnu.org
>>> 
>>> I think I understand the issue, but not its solution. There are more or less three standard ways to change
>>> faces now: Customize, themes, and use-package :custom-face. But there is no clear way to resolve the
>>> ordering between them, or whether they replace or inherit at each level. The behavior I was surprised by,
>>> and that has been reported previously, is that there was no way to specify a replacement for face settings.
>>> But Steven is surprised by the fact that things now happen at a level below theme application, and the theme
>>> replaces instead of inherits the defface spec.
>
>> John, could you perhaps help us out here?  Bug#77928 was about
>> :custom-face, which is a use-package feature.  I don't really
>> understand how this feature is supposed to work, given that
>> use-package produces macros whose effect happens when a package is
>> loaded, and given that other methods of face definition are available.
>
> All that use-package is doing here is expanding the ‘:custom-face‘ declaration
> into this call:
>
>   (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))
>
> Should it be calling something other than `face-spec-set' now?

That's what it used to be before the change in question. Now it expands
to:

     (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t)) face-defface-spec))

The issue here is that the themed face spec has a higher priority than
the "defface" spec. IMO, this should be reverted to just:

     (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))

(leaving the part of the patch that marks the face as "modified" intact).

From what I can tell, the patch in question was attempting to solve an
issue where overriding faces get "merged" with "lower" priority face
specs but, IMO, that isn't really a bug.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: 77928 <at> debbugs.gnu.org, johnw <at> gnu.org, shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Tue, 27 May 2025 14:23:08 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: Michael Shields <shields <at> msrl.com>, 77928 <at> debbugs.gnu.org
> Date: Mon, 26 May 2025 18:26:24 -0700
> 
> John Wiegley <johnw <at> gnu.org> writes:
> 
> >>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >>> From: Michael Shields <shields <at> msrl.com>
> >>> Date: Mon, 19 May 2025 22:51:29 -0700
> >>> Cc: steven <at> stebalien.com, 77928 <at> debbugs.gnu.org
> >>> 
> >>> I think I understand the issue, but not its solution. There are more or less three standard ways to change
> >>> faces now: Customize, themes, and use-package :custom-face. But there is no clear way to resolve the
> >>> ordering between them, or whether they replace or inherit at each level. The behavior I was surprised by,
> >>> and that has been reported previously, is that there was no way to specify a replacement for face settings.
> >>> But Steven is surprised by the fact that things now happen at a level below theme application, and the theme
> >>> replaces instead of inherits the defface spec.
> >
> >> John, could you perhaps help us out here?  Bug#77928 was about
> >> :custom-face, which is a use-package feature.  I don't really
> >> understand how this feature is supposed to work, given that
> >> use-package produces macros whose effect happens when a package is
> >> loaded, and given that other methods of face definition are available.
> >
> > All that use-package is doing here is expanding the ‘:custom-face‘ declaration
> > into this call:
> >
> >   (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))
> >
> > Should it be calling something other than `face-spec-set' now?
> 
> That's what it used to be before the change in question. Now it expands
> to:
> 
>      (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t)) face-defface-spec))
> 
> The issue here is that the themed face spec has a higher priority than
> the "defface" spec.

But AFAIU, face-defface-spec records the theme customizations of the
face as well, no?  I'm afraid I don't quite understand what you are
saying here, could you please explain and elaborate?

> IMO, this should be reverted to just:
> 
>      (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))
> 
> (leaving the part of the patch that marks the face as "modified" intact).
> 
> >From what I can tell, the patch in question was attempting to solve an
> issue where overriding faces get "merged" with "lower" priority face
> specs but, IMO, that isn't really a bug.

Why don't you consider that a bug?

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

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, johnw <at> gnu.org, shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Tue, 27 May 2025 09:38:28 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Steven Allen <steven <at> stebalien.com>
>> Cc: Michael Shields <shields <at> msrl.com>, 77928 <at> debbugs.gnu.org
>> Date: Mon, 26 May 2025 18:26:24 -0700
>>
>> John Wiegley <johnw <at> gnu.org> writes:
>>
>> >>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >
>> >>> From: Michael Shields <shields <at> msrl.com>
>> >>> Date: Mon, 19 May 2025 22:51:29 -0700
>> >>> Cc: steven <at> stebalien.com, 77928 <at> debbugs.gnu.org
>> >>>
>> >>> I think I understand the issue, but not its solution. There are more or less three standard ways to change
>> >>> faces now: Customize, themes, and use-package :custom-face. But there is no clear way to resolve the
>> >>> ordering between them, or whether they replace or inherit at each level. The behavior I was surprised by,
>> >>> and that has been reported previously, is that there was no way to specify a replacement for face settings.
>> >>> But Steven is surprised by the fact that things now happen at a level below theme application, and the theme
>> >>> replaces instead of inherits the defface spec.
>> >
>> >> John, could you perhaps help us out here?  Bug#77928 was about
>> >> :custom-face, which is a use-package feature.  I don't really
>> >> understand how this feature is supposed to work, given that
>> >> use-package produces macros whose effect happens when a package is
>> >> loaded, and given that other methods of face definition are available.
>> >
>> > All that use-package is doing here is expanding the ‘:custom-face‘ declaration
>> > into this call:
>> >
>> >   (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))
>> >
>> > Should it be calling something other than `face-spec-set' now?
>>
>> That's what it used to be before the change in question. Now it expands
>> to:
>>
>>      (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t)) face-defface-spec))
>>
>> The issue here is that the themed face spec has a higher priority than
>> the "defface" spec.
>
> But AFAIU, face-defface-spec records the theme customizations of the
> face as well, no?  I'm afraid I don't quite understand what you are
> saying here, could you please explain and elaborate?

face-defface-spec is only used when declaring faces, not when
customizing/theming them. The theme-face property is used to store the
themed face, customized-face is used to store customizations through the
"custom" system, and face-override-spec is used otherwise.

You can look at a face's plist to get a better idea of how this works:

    (symbol-plist 'default)

Also look at the documentation for facep-spec-recalc: theme and/or user
customizations override the "defface" spec, causing the bug I'm seeing here.

>> IMO, this should be reverted to just:
>>
>>      (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))
>>
>> (leaving the part of the patch that marks the face as "modified" intact).
>>
>> >From what I can tell, the patch in question was attempting to solve an
>> issue where overriding faces get "merged" with "lower" priority face
>> specs but, IMO, that isn't really a bug.
>
> Why don't you consider that a bug?

That's how face customization works. E.g.:

    (custom-set-faces '(font-lock-keyword-face ((t :italic t)) t))

Will make keywords italic but won't override the theme/defaults unless
requested. E.g.:

    (custom-set-faces
      '(font-lock-keyword-face ((t :italic t :foreground unspecified)) t))

Will "unset" the foreground (it'll inherit from the face's parent). And:

    (custom-set-faces
      '(font-lock-keyword-face ((t :italic t :foreground reset)) t))

Will "reset" the foreground to the default face's foreground.

This makes it possible to compose/modify faces without completely
overriding them. E.g., if you want a specific face to be bold/italic but
otherwise want the underlying theme to apply. This makes it possible to,
e.g., customize certain aspects of faces across themes.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: 77928 <at> debbugs.gnu.org, johnw <at> gnu.org, shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Wed, 28 May 2025 14:10:37 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: johnw <at> gnu.org, shields <at> msrl.com, 77928 <at> debbugs.gnu.org
> Date: Tue, 27 May 2025 09:38:28 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Steven Allen <steven <at> stebalien.com>
> >> Cc: Michael Shields <shields <at> msrl.com>, 77928 <at> debbugs.gnu.org
> >> Date: Mon, 26 May 2025 18:26:24 -0700
> >>
> >> John Wiegley <johnw <at> gnu.org> writes:
> >>
> >> >>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> >
> >> >>> From: Michael Shields <shields <at> msrl.com>
> >> >>> Date: Mon, 19 May 2025 22:51:29 -0700
> >> >>> Cc: steven <at> stebalien.com, 77928 <at> debbugs.gnu.org
> >> >>>
> >> >>> I think I understand the issue, but not its solution. There are more or less three standard ways to change
> >> >>> faces now: Customize, themes, and use-package :custom-face. But there is no clear way to resolve the
> >> >>> ordering between them, or whether they replace or inherit at each level. The behavior I was surprised by,
> >> >>> and that has been reported previously, is that there was no way to specify a replacement for face settings.
> >> >>> But Steven is surprised by the fact that things now happen at a level below theme application, and the theme
> >> >>> replaces instead of inherits the defface spec.
> >> >
> >> >> John, could you perhaps help us out here?  Bug#77928 was about
> >> >> :custom-face, which is a use-package feature.  I don't really
> >> >> understand how this feature is supposed to work, given that
> >> >> use-package produces macros whose effect happens when a package is
> >> >> loaded, and given that other methods of face definition are available.
> >> >
> >> > All that use-package is doing here is expanding the ‘:custom-face‘ declaration
> >> > into this call:
> >> >
> >> >   (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))
> >> >
> >> > Should it be calling something other than `face-spec-set' now?
> >>
> >> That's what it used to be before the change in question. Now it expands
> >> to:
> >>
> >>      (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t)) face-defface-spec))
> >>
> >> The issue here is that the themed face spec has a higher priority than
> >> the "defface" spec.
> >
> > But AFAIU, face-defface-spec records the theme customizations of the
> > face as well, no?  I'm afraid I don't quite understand what you are
> > saying here, could you please explain and elaborate?
> 
> face-defface-spec is only used when declaring faces, not when
> customizing/theming them. The theme-face property is used to store the
> themed face, customized-face is used to store customizations through the
> "custom" system, and face-override-spec is used otherwise.
> 
> You can look at a face's plist to get a better idea of how this works:
> 
>     (symbol-plist 'default)
> 
> Also look at the documentation for facep-spec-recalc: theme and/or user
> customizations override the "defface" spec, causing the bug I'm seeing here.
> 
> >> IMO, this should be reverted to just:
> >>
> >>      (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))
> >>
> >> (leaving the part of the patch that marks the face as "modified" intact).
> >>
> >> >From what I can tell, the patch in question was attempting to solve an
> >> issue where overriding faces get "merged" with "lower" priority face
> >> specs but, IMO, that isn't really a bug.
> >
> > Why don't you consider that a bug?
> 
> That's how face customization works. E.g.:
> 
>     (custom-set-faces '(font-lock-keyword-face ((t :italic t)) t))
> 
> Will make keywords italic but won't override the theme/defaults unless
> requested. E.g.:
> 
>     (custom-set-faces
>       '(font-lock-keyword-face ((t :italic t :foreground unspecified)) t))
> 
> Will "unset" the foreground (it'll inherit from the face's parent). And:
> 
>     (custom-set-faces
>       '(font-lock-keyword-face ((t :italic t :foreground reset)) t))
> 
> Will "reset" the foreground to the default face's foreground.
> 
> This makes it possible to compose/modify faces without completely
> overriding them. E.g., if you want a specific face to be bold/italic but
> otherwise want the underlying theme to apply. This makes it possible to,
> e.g., customize certain aspects of faces across themes.

Thanks.

Unfortunately, what you say above seems to assume the level of
detailed knowledge in themes, use-package, and their interactions with
Customize that I don't have.  I think I know how faces work and how
face merging works, but after reading your explanations and examples
several times I'm sorry to say that I'm utterly confused by what you
say and don't have any clear idea about the problem, its consequences,
and your analysis of the original issue and its fix.

So either someone explains this to me in terms I can understand and
reason about, or we will need to wait for someone more knowledgeable
in this stuff to pick up the gauntlet.

Alternatively, if you convince John and Michael that the changes you
think should be done are indeed the way to go, I will gladly delegate
the decision to you three.

Sorry I couldn't be of more help.

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

From: John Wiegley <johnw <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, Steven Allen <steven <at> stebalien.com>,
 shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Wed, 28 May 2025 10:01:03 -0700

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

> So either someone explains this to me in terms I can understand and reason
> about, or we will need to wait for someone more knowledgeable in this stuff
> to pick up the gauntlet.

> Alternatively, if you convince John and Michael that the changes you think
> should be done are indeed the way to go, I will gladly delegate the decision
> to you three.

I’m not an expert in face customization either, so I really can’t weigh in on
the merits of this change. I’d love a deep explanation also!

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#77928: 31.0.50;
 ebcde0f90f6 (bug#77928) breaks :custom-face for themed faces
Date: Fri, 30 May 2025 19:23:38 +0100

On Wed 28 May 2025, Eli Zaretskii wrote:

>> From: Steven Allen <steven <at> stebalien.com>
>> Cc: johnw <at> gnu.org, shields <at> msrl.com, 77928 <at> debbugs.gnu.org
>> Date: Tue, 27 May 2025 09:38:28 -0700
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Steven Allen <steven <at> stebalien.com>
>> >> Cc: Michael Shields <shields <at> msrl.com>, 77928 <at> debbugs.gnu.org
>> >> Date: Mon, 26 May 2025 18:26:24 -0700
>> >>
>> >> John Wiegley <johnw <at> gnu.org> writes:
>> >>
>> >> >>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> >
>> >> >>> From: Michael Shields <shields <at> msrl.com>
>> >> >>> Date: Mon, 19 May 2025 22:51:29 -0700
>> >> >>> Cc: steven <at> stebalien.com, 77928 <at> debbugs.gnu.org
>> >> >>>
>> >> >>> I think I understand the issue, but not its solution. There are more or less three standard ways to change
>> >> >>> faces now: Customize, themes, and use-package :custom-face. But there is no clear way to resolve the
>> >> >>> ordering between them, or whether they replace or inherit at each level. The behavior I was surprised by,
>> >> >>> and that has been reported previously, is that there was no way to specify a replacement for face settings.
>> >> >>> But Steven is surprised by the fact that things now happen at a level below theme application, and the theme
>> >> >>> replaces instead of inherits the defface spec.
>> >> >
>> >> >> John, could you perhaps help us out here?  Bug#77928 was about
>> >> >> :custom-face, which is a use-package feature.  I don't really
>> >> >> understand how this feature is supposed to work, given that
>> >> >> use-package produces macros whose effect happens when a package is
>> >> >> loaded, and given that other methods of face definition are available.
>> >> >
>> >> > All that use-package is doing here is expanding the ‘:custom-face‘ declaration
>> >> > into this call:
>> >> >
>> >> >   (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))
>> >> >
>> >> > Should it be calling something other than `face-spec-set' now?
>> >>
>> >> That's what it used to be before the change in question. Now it expands
>> >> to:
>> >>
>> >>      (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t)) face-defface-spec))
>> >>
>> >> The issue here is that the themed face spec has a higher priority than
>> >> the "defface" spec.
>> >
>> > But AFAIU, face-defface-spec records the theme customizations of the
>> > face as well, no?  I'm afraid I don't quite understand what you are
>> > saying here, could you please explain and elaborate?
>> 
>> face-defface-spec is only used when declaring faces, not when
>> customizing/theming them. The theme-face property is used to store the
>> themed face, customized-face is used to store customizations through the
>> "custom" system, and face-override-spec is used otherwise.
>> 
>> You can look at a face's plist to get a better idea of how this works:
>> 
>>     (symbol-plist 'default)
>> 
>> Also look at the documentation for facep-spec-recalc: theme and/or user
>> customizations override the "defface" spec, causing the bug I'm seeing here.
>> 
>> >> IMO, this should be reverted to just:
>> >>
>> >>      (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))
>> >>
>> >> (leaving the part of the patch that marks the face as "modified" intact).
>> >>
>> >> >From what I can tell, the patch in question was attempting to solve an
>> >> issue where overriding faces get "merged" with "lower" priority face
>> >> specs but, IMO, that isn't really a bug.
>> >
>> > Why don't you consider that a bug?
>> 
>> That's how face customization works. E.g.:
>> 
>>     (custom-set-faces '(font-lock-keyword-face ((t :italic t)) t))
>> 
>> Will make keywords italic but won't override the theme/defaults unless
>> requested. E.g.:
>> 
>>     (custom-set-faces
>>       '(font-lock-keyword-face ((t :italic t :foreground unspecified)) t))
>> 
>> Will "unset" the foreground (it'll inherit from the face's parent). And:
>> 
>>     (custom-set-faces
>>       '(font-lock-keyword-face ((t :italic t :foreground reset)) t))
>> 
>> Will "reset" the foreground to the default face's foreground.
>> 
>> This makes it possible to compose/modify faces without completely
>> overriding them. E.g., if you want a specific face to be bold/italic but
>> otherwise want the underlying theme to apply. This makes it possible to,
>> e.g., customize certain aspects of faces across themes.
>
> Thanks.
>
> Unfortunately, what you say above seems to assume the level of
> detailed knowledge in themes, use-package, and their interactions with
> Customize that I don't have.  I think I know how faces work and how
> face merging works, but after reading your explanations and examples
> several times I'm sorry to say that I'm utterly confused by what you
> say and don't have any clear idea about the problem, its consequences,
> and your analysis of the original issue and its fix.
>
> So either someone explains this to me in terms I can understand and
> reason about, or we will need to wait for someone more knowledgeable
> in this stuff to pick up the gauntlet.
>
> Alternatively, if you convince John and Michael that the changes you
> think should be done are indeed the way to go, I will gladly delegate
> the decision to you three.
>
> Sorry I couldn't be of more help.

I'm not at all expert, but this effect is easily reproducible.
Using the mingw64 build on Windows:

a) build from master, and start with "runemacs.exe -Q"
b) in the scratch buffer, evaluate:
  (use-package faces
    :custom-face
    (default
     ((((class color)) :font "DejaVu Sans Mono-9" :background "gray85")))
    (variable-pitch
     ((((class color)) :font "Liberation Sans-10"))) )

c) Display a tooltip e.g. from moving the mouse over the major mode
   indicator on the modeline. The tooltip is shown using a monospaced
   font, even though the tooltip face inherits from variable-pitch.

d) "M-x describe-face RET tooltip RET" shows the tooltip face as
   expected, with the sample text in a variable pitch font.

e) Repeat all steps, but instead of (b), evaluate:
  (use-package faces
    :init
    (apply #'face-spec-set
           '(variable-pitch
             ((((class color)) :font "Liberation Sans-11"))))
    :custom-face
    (default
     ((((class color)) :font "DejaVu Sans Mono-9" :background "gray85")))
    )

   That produces the expected variable pitch font for the tooltip.


Thus this is not working properly, even without interaction with themes.

    AndyM

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 77928 <at> debbugs.gnu.org, Steven Allen <steven <at> stebalien.com>,
 shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50;
 ebcde0f90f6 (bug#77928) breaks :custom-face for themed faces
Date: Sat, 31 May 2025 09:44:23 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Fri, 30 May 2025 19:23:38 +0100
> 
> On Wed 28 May 2025, Eli Zaretskii wrote:
> 
> > Unfortunately, what you say above seems to assume the level of
> > detailed knowledge in themes, use-package, and their interactions with
> > Customize that I don't have.  I think I know how faces work and how
> > face merging works, but after reading your explanations and examples
> > several times I'm sorry to say that I'm utterly confused by what you
> > say and don't have any clear idea about the problem, its consequences,
> > and your analysis of the original issue and its fix.
> >
> > So either someone explains this to me in terms I can understand and
> > reason about, or we will need to wait for someone more knowledgeable
> > in this stuff to pick up the gauntlet.
> >
> > Alternatively, if you convince John and Michael that the changes you
> > think should be done are indeed the way to go, I will gladly delegate
> > the decision to you three.
> >
> > Sorry I couldn't be of more help.
> 
> I'm not at all expert, but this effect is easily reproducible.
> Using the mingw64 build on Windows:
> 
> a) build from master, and start with "runemacs.exe -Q"
> b) in the scratch buffer, evaluate:
>   (use-package faces
>     :custom-face
>     (default
>      ((((class color)) :font "DejaVu Sans Mono-9" :background "gray85")))
>     (variable-pitch
>      ((((class color)) :font "Liberation Sans-10"))) )
> 
> c) Display a tooltip e.g. from moving the mouse over the major mode
>    indicator on the modeline. The tooltip is shown using a monospaced
>    font, even though the tooltip face inherits from variable-pitch.
> 
> d) "M-x describe-face RET tooltip RET" shows the tooltip face as
>    expected, with the sample text in a variable pitch font.
> 
> e) Repeat all steps, but instead of (b), evaluate:
>   (use-package faces
>     :init
>     (apply #'face-spec-set
>            '(variable-pitch
>              ((((class color)) :font "Liberation Sans-11"))))
>     :custom-face
>     (default
>      ((((class color)) :font "DejaVu Sans Mono-9" :background "gray85")))
>     )
> 
>    That produces the expected variable pitch font for the tooltip.
> 
> 
> Thus this is not working properly, even without interaction with themes.

Thanks.  Unfortunately, I'm not a bit wiser after reading your recipe
for several times (I don't have the Liberation Sans font here to fully
reproduce it).  You are showing the results using use-package, which I
don't use and know very little about, and John did agree with the
original patch back when it was proposed.

So I'm still unable to decide what to do with this, because I don't
understands well enough what is going on and what is being claimed.

But maybe someone else of the participants (whom you elided, and I
added back now) could understand better what you said, and explain it
or suggest a solution.

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

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, johnw <at> gnu.org, shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Wed, 04 Jun 2025 12:07:12 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Steven Allen <steven <at> stebalien.com>
>> Cc: johnw <at> gnu.org, shields <at> msrl.com, 77928 <at> debbugs.gnu.org
>> Date: Tue, 27 May 2025 09:38:28 -0700
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Steven Allen <steven <at> stebalien.com>
>> >> Cc: Michael Shields <shields <at> msrl.com>, 77928 <at> debbugs.gnu.org
>> >> Date: Mon, 26 May 2025 18:26:24 -0700
>> >>
>> >> John Wiegley <johnw <at> gnu.org> writes:
>> >>
>> >> >>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> >
>> >> >>> From: Michael Shields <shields <at> msrl.com>
>> >> >>> Date: Mon, 19 May 2025 22:51:29 -0700
>> >> >>> Cc: steven <at> stebalien.com, 77928 <at> debbugs.gnu.org
>> >> >>>
>> >> >>> I think I understand the issue, but not its solution. There are more or less three standard ways to change
>> >> >>> faces now: Customize, themes, and use-package :custom-face. But there is no clear way to resolve the
>> >> >>> ordering between them, or whether they replace or inherit at each level. The behavior I was surprised by,
>> >> >>> and that has been reported previously, is that there was no way to specify a replacement for face settings.
>> >> >>> But Steven is surprised by the fact that things now happen at a level below theme application, and the theme
>> >> >>> replaces instead of inherits the defface spec.
>> >> >
>> >> >> John, could you perhaps help us out here?  Bug#77928 was about
>> >> >> :custom-face, which is a use-package feature.  I don't really
>> >> >> understand how this feature is supposed to work, given that
>> >> >> use-package produces macros whose effect happens when a package is
>> >> >> loaded, and given that other methods of face definition are available.
>> >> >
>> >> > All that use-package is doing here is expanding the ‘:custom-face‘ declaration
>> >> > into this call:
>> >> >
>> >> >   (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))
>> >> >
>> >> > Should it be calling something other than `face-spec-set' now?
>> >>
>> >> That's what it used to be before the change in question. Now it expands
>> >> to:
>> >>
>> >>      (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t)) face-defface-spec))
>> >>
>> >> The issue here is that the themed face spec has a higher priority than
>> >> the "defface" spec.
>> >
>> > But AFAIU, face-defface-spec records the theme customizations of the
>> > face as well, no?  I'm afraid I don't quite understand what you are
>> > saying here, could you please explain and elaborate?
>>
>> face-defface-spec is only used when declaring faces, not when
>> customizing/theming them. The theme-face property is used to store the
>> themed face, customized-face is used to store customizations through the
>> "custom" system, and face-override-spec is used otherwise.
>>
>> You can look at a face's plist to get a better idea of how this works:
>>
>>     (symbol-plist 'default)
>>
>> Also look at the documentation for facep-spec-recalc: theme and/or user
>> customizations override the "defface" spec, causing the bug I'm seeing here.
>>
>> >> IMO, this should be reverted to just:
>> >>
>> >>      (apply #'face-spec-set '(font-lock-keyword-face ((t :italic t))))
>> >>
>> >> (leaving the part of the patch that marks the face as "modified" intact).
>> >>
>> >> >From what I can tell, the patch in question was attempting to solve an
>> >> issue where overriding faces get "merged" with "lower" priority face
>> >> specs but, IMO, that isn't really a bug.
>> >
>> > Why don't you consider that a bug?
>>
>> That's how face customization works. E.g.:
>>
>>     (custom-set-faces '(font-lock-keyword-face ((t :italic t)) t))
>>
>> Will make keywords italic but won't override the theme/defaults unless
>> requested. E.g.:
>>
>>     (custom-set-faces
>>       '(font-lock-keyword-face ((t :italic t :foreground unspecified)) t))
>>
>> Will "unset" the foreground (it'll inherit from the face's parent). And:
>>
>>     (custom-set-faces
>>       '(font-lock-keyword-face ((t :italic t :foreground reset)) t))
>>
>> Will "reset" the foreground to the default face's foreground.
>>
>> This makes it possible to compose/modify faces without completely
>> overriding them. E.g., if you want a specific face to be bold/italic but
>> otherwise want the underlying theme to apply. This makes it possible to,
>> e.g., customize certain aspects of faces across themes.
>
> Thanks.
>
> Unfortunately, what you say above seems to assume the level of
> detailed knowledge in themes, use-package, and their interactions with
> Customize that I don't have.  I think I know how faces work and how
> face merging works, but after reading your explanations and examples
> several times I'm sorry to say that I'm utterly confused by what you
> say and don't have any clear idea about the problem, its consequences,
> and your analysis of the original issue and its fix.
>
> So either someone explains this to me in terms I can understand and
> reason about, or we will need to wait for someone more knowledgeable
> in this stuff to pick up the gauntlet.
>
> Alternatively, if you convince John and Michael that the changes you
> think should be done are indeed the way to go, I will gladly delegate
> the decision to you three.
>
> Sorry I couldn't be of more help.

Unfortunately, my understanding is also very limited. Instead of trying
to explain the code (which I barely understand) I'll focus on explaining
the symptoms and my expectations.

There are two parts to this report:

1. Bug: use-package's ":custom-face" no longer overrides themed
  faces.
2. Opinion: ":custom-face" SHOULD merge the user-specified face spec
  with the underlying face spec (contrary to the original report).

**First Part (the clear bug)**

Before the commit in question, the :custom-face use-package keyword
(effectively†) expanded to:

    (face-spec-set face spec)

Now, it (effectively‡) expands to:

    (face-spec-set face spec 'face-defface-spec)

This is a problem because this new code sets the DEFAULT spec for the
face while themes override the default spec. This means user
customizations via ":custom-face" fail to override the theme.

† Technically, it used to expand to (where "def" is `(FACE SPEC)'):

    (apply #'face-spec-set (backquote ,def))

‡ Technically, it now expands to:

    (progn
       (apply #'face-spec-set (append (backquote ,def) '(face-defface-spec)))
       (put ',(car def) 'face-modified t))

**Second Part**

IMO, :custom-face SHOULD behave like "custom-set-faces". Faces
specs applied via "custom-set-faces" are MERGED with the underlying face
(as use-package's ":custom-face" used to do behave). You can test this
behavior by opening any syntax-highlighted code and evaluating:

    (custom-set-faces '(font-lock-keyword-face ((t :italic t)) t))

All keywords will be made italic but will otherwise retain their coloring.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: 77928 <at> debbugs.gnu.org, johnw <at> gnu.org, shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sat, 07 Jun 2025 12:49:12 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: johnw <at> gnu.org, shields <at> msrl.com, 77928 <at> debbugs.gnu.org
> Date: Wed, 04 Jun 2025 12:07:12 -0700
> 
> There are two parts to this report:
> 
> 1. Bug: use-package's ":custom-face" no longer overrides themed
>   faces.
> 2. Opinion: ":custom-face" SHOULD merge the user-specified face spec
>   with the underlying face spec (contrary to the original report).

I'm not sure I agree.  I think the concept is that themes override any
other face definitions, otherwise themes couldn't have done their main
job.

> IMO, :custom-face SHOULD behave like "custom-set-faces".

Not sure I agree, but maybe John could state his opinions on that?

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

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, johnw <at> gnu.org, shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sat, 07 Jun 2025 09:09:03 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Steven Allen <steven <at> stebalien.com>
>> Cc: johnw <at> gnu.org, shields <at> msrl.com, 77928 <at> debbugs.gnu.org
>> Date: Wed, 04 Jun 2025 12:07:12 -0700
>>
>> There are two parts to this report:
>>
>> 1. Bug: use-package's ":custom-face" no longer overrides themed
>>   faces.
>> 2. Opinion: ":custom-face" SHOULD merge the user-specified face spec
>>   with the underlying face spec (contrary to the original report).
>
> I'm not sure I agree.  I think the concept is that themes override any
> other face definitions, otherwise themes couldn't have done their main
> job.

But this is the user's config. The theme should (and does) override the
default face definitions, but the user should always have the last say.

For example, if a user customizes a face via the "Easy Customization"
interface, said customizations always override the theme. :custom-face
is supposed to be the use-package equivalent of the "Easy
Customization" system.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: 77928 <at> debbugs.gnu.org, johnw <at> gnu.org, shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sat, 07 Jun 2025 20:15:46 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: johnw <at> gnu.org, shields <at> msrl.com, 77928 <at> debbugs.gnu.org
> Date: Sat, 07 Jun 2025 09:09:03 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Steven Allen <steven <at> stebalien.com>
> >> Cc: johnw <at> gnu.org, shields <at> msrl.com, 77928 <at> debbugs.gnu.org
> >> Date: Wed, 04 Jun 2025 12:07:12 -0700
> >>
> >> There are two parts to this report:
> >>
> >> 1. Bug: use-package's ":custom-face" no longer overrides themed
> >>   faces.
> >> 2. Opinion: ":custom-face" SHOULD merge the user-specified face spec
> >>   with the underlying face spec (contrary to the original report).
> >
> > I'm not sure I agree.  I think the concept is that themes override any
> > other face definitions, otherwise themes couldn't have done their main
> > job.
> 
> But this is the user's config. The theme should (and does) override the
> default face definitions, but the user should always have the last say.

Loading a theme is also a user configuration.  Customizing a face
directly (via "M-x customize-face") should indeed take precedence, but
use-package's :custom-face isn't that, AFAIU, because it doesn't
expand to a custom-set-faces form.

In fact, I'm not sure I understand the semantics of use-package's
:custom-face attribute.  And what is supposed to happen if a theme is
loaded _after_ :custom-face was processed?

> For example, if a user customizes a face via the "Easy Customization"
> interface, said customizations always override the theme. :custom-face
> is supposed to be the use-package equivalent of the "Easy
> Customization" system.

I'm not sure this is what :custom-face is, because it expands to
something else.  Maybe John could help us understand what was the
intent, and why this is the expansion.

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

From: John Wiegley <johnw <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, Steven Allen <steven <at> stebalien.com>,
 shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sun, 08 Jun 2025 00:56:32 -0700

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

>> For example, if a user customizes a face via the "Easy Customization"
>> interface, said customizations always override the theme. :custom-face is
>> supposed to be the use-package equivalent of the "Easy Customization"
>> system.

> I'm not sure this is what :custom-face is, because it expands to something
> else. Maybe John could help us understand what was the intent, and why this
> is the expansion.

This is no deep answer, I’m afraid. I think I just looked at what gets called
in settings.el when you save a face customization (`custom-set-faces'), and so
this is what I used.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Steven Allen <steven <at> stebalien.com>
To: John Wiegley <johnw <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sun, 08 Jun 2025 09:17:02 -0700

John Wiegley <johnw <at> gnu.org> writes:

>>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> For example, if a user customizes a face via the "Easy Customization"
>>> interface, said customizations always override the theme. :custom-face is
>>> supposed to be the use-package equivalent of the "Easy Customization"
>>> system.
>
>> I'm not sure this is what :custom-face is, because it expands to something
>> else. Maybe John could help us understand what was the intent, and why this
>> is the expansion.
>
> This is no deep answer, I’m afraid. I think I just looked at what gets called
> in settings.el when you save a face customization (`custom-set-faces'), and so
> this is what I used.

It would help to better understand how it was intended to behave:

- Should :custom-face override the theme or should the theme override
  :custom-face?

- Should customizations made via :custom-face be merged with the
  original face definition (as with `custom-set-faces') or should they
  completely replace the underlying face.

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

From: John Wiegley <johnw <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, shields <at> msrl.com, 77928 <at> debbugs.gnu.org
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sun, 08 Jun 2025 10:46:14 -0700

>>>>> Steven Allen <steven <at> stebalien.com> writes:

> It would help to better understand how it was intended to behave:

> - Should :custom-face override the theme or should the theme override
>   :custom-face?

I’ve never used themes before, so I wasn’t thinking of them at all when the
feature was added. Someone who uses themes a lot, and customizes them, should
be asked this question.

> - Should customizations made via :custom-face be merged with the original
>   face definition (as with `custom-set-faces') or should they completely
>   replace the underlying face.

I would expect the behavior to be whatever `custom-set-faces' does. Since
use-package is only intended to expand to “best practice” Emacs Lisp, it
shouldn’t add any new behavior in my opinion.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Michael Shields <shields <at> msrl.com>
To: John Wiegley <johnw <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Steven Allen <steven <at> stebalien.com>,
 77928 <at> debbugs.gnu.org
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sun, 8 Jun 2025 11:27:37 -0700

[Message part 1 (text/plain, inline)]

I don't use themes either, but I can describe my use case.

I refactored much of my Emacs config into use-package. Most of that went
straightforwardly into :init, :bind, :hook, etc. Custom variables moved to
:custom, and custom faces moved to :custom-face. But this caused some faces
to change, because custom-set-faces effectively replaces the face
definition, while :custom-face overlaid it.

If I understand the history, :custom-face initially called
custom-set-faces, so it behaved identically to having custom-set-faces in
custom.el. But this confusingly resulted in :custom-face definitions being
written to custom.el as if the user had configured them through M-x
customize. https://github.com/jwiegley/use-package/pull/1004 fixed that,
unintentionally also changing the semantics of :custom-face.

With my patch applied, :custom-face should be equivalent in behavior to
custom-set-faces, but without the settings appearing as if they were
user-set.

I don't know how this should interact with themes. Maybe the right approach
there is to define a new personal theme and configure faces there instead
of using :custom-face. Or maybe it is simplest to call face-spec-set
explicitly from :config.


On Sun, Jun 8, 2025 at 10:46 AM John Wiegley <johnw <at> gnu.org> wrote:

> >>>>> Steven Allen <steven <at> stebalien.com> writes:
>
> > It would help to better understand how it was intended to behave:
>
> > - Should :custom-face override the theme or should the theme override
> >   :custom-face?
>
> I’ve never used themes before, so I wasn’t thinking of them at all when the
> feature was added. Someone who uses themes a lot, and customizes them,
> should
> be asked this question.
>
> > - Should customizations made via :custom-face be merged with the original
> >   face definition (as with `custom-set-faces') or should they completely
> >   replace the underlying face.
>
> I would expect the behavior to be whatever `custom-set-faces' does. Since
> use-package is only intended to expand to “best practice” Emacs Lisp, it
> shouldn’t add any new behavior in my opinion.
>
> --
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>

[Message part 2 (text/html, inline)]

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

From: John Wiegley <johnw <at> gnu.org>
To: Michael Shields <shields <at> msrl.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Steven Allen <steven <at> stebalien.com>,
 77928 <at> debbugs.gnu.org
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sun, 08 Jun 2025 11:31:38 -0700

>>>>> Michael Shields <shields <at> msrl.com> writes:

> With my patch applied, :custom-face should be equivalent in behavior to
> custom-set-faces, but without the settings appearing as if they were
> user-set.

> I don't know how this should interact with themes. Maybe the right approach
> there is to define a new personal theme and configure faces there instead of
> using :custom-face. Or maybe it is simplest to call face-spec-set explicitly
> from :config.

This description certainly sounds like it expresses the right approach of
use-package being as “minimal” a wrapper around standard behavior as possible.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Kristoffer Balintona <krisbalintona <at> gmail.com>
To: John Wiegley <johnw <at> gnu.org>, Steven Allen <steven <at> stebalien.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, shields <at> msrl.com, 77928 <at> debbugs.gnu.org
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sun, 8 Jun 2025 11:40:55 -0700

On Sun, Jun 08 2025, John Wiegley wrote:

>>>>>> Steven Allen <steven <at> stebalien.com> writes:
>
>> It would help to better understand how it was intended to behave:
>
>> - Should :custom-face override the theme or should the theme override
>>   :custom-face?
>
> I’ve never used themes before, so I wasn’t thinking of them at all when the
> feature was added. Someone who uses themes a lot, and customizes them, should
> be asked this question.

FWIW, I haven’t been following this thread closely, but as a user who
hadn’t thought at all about the technical sides of things, what I simply
expected of :custom-face was that it be applied on top of any existing
theme customizations, not that it override them.

Again, that’s my un-technical, naive expectation as a user. Just
throwing in my experience.

-- 
Kind regards,
Kristoffer

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: John Wiegley <johnw <at> gnu.org>
Cc: 77928 <at> debbugs.gnu.org, steven <at> stebalien.com, shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sun, 08 Jun 2025 22:04:17 +0300

> From: John Wiegley <johnw <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  shields <at> msrl.com,  77928 <at> debbugs.gnu.org
> Date: Sun, 08 Jun 2025 10:46:14 -0700
> 
> >>>>> Steven Allen <steven <at> stebalien.com> writes:
> 
> > - Should customizations made via :custom-face be merged with the original
> >   face definition (as with `custom-set-faces') or should they completely
> >   replace the underlying face.
> 
> I would expect the behavior to be whatever `custom-set-faces' does. Since
> use-package is only intended to expand to “best practice” Emacs Lisp, it
> shouldn’t add any new behavior in my opinion.

Then IMO :custom-face should expand into a call to custom-set-faces.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kristoffer Balintona <krisbalintona <at> gmail.com>
Cc: 77928 <at> debbugs.gnu.org, johnw <at> gnu.org, steven <at> stebalien.com,
 shields <at> msrl.com
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sun, 08 Jun 2025 22:10:03 +0300

> From: Kristoffer Balintona <krisbalintona <at> gmail.com>
> Date: Sun, 8 Jun 2025 11:40:55 -0700
> Cc: Eli Zaretskii <eliz <at> gnu.org>, shields <at> msrl.com, 77928 <at> debbugs.gnu.org
> 
> On Sun, Jun 08 2025, John Wiegley wrote:
> 
> >>>>>> Steven Allen <steven <at> stebalien.com> writes:
> >
> >> It would help to better understand how it was intended to behave:
> >
> >> - Should :custom-face override the theme or should the theme override
> >>   :custom-face?
> >
> > I’ve never used themes before, so I wasn’t thinking of them at all when the
> > feature was added. Someone who uses themes a lot, and customizes them, should
> > be asked this question.
> 
> FWIW, I haven’t been following this thread closely, but as a user who
> hadn’t thought at all about the technical sides of things, what I simply
> expected of :custom-face was that it be applied on top of any existing
> theme customizations, not that it override them.

Thanks, but what is your mental model of "applied on top" vs
"override", in the context of face settings?  Unless you explain that,
I cannot understand what are your expectations, because "applied on
top" and "override" are not useful descriptions when talking about
faces, due to the fact that a face has quite a few attributes, and
some of them could be inherited from other faces.

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

From: Steven Allen <steven <at> stebalien.com>
To: Michael Shields <shields <at> msrl.com>, John Wiegley <johnw <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77928 <at> debbugs.gnu.org
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sun, 08 Jun 2025 12:25:28 -0700

Michael Shields <shields <at> msrl.com> writes:

> I don't use themes either, but I can describe my use case.
>
> I refactored much of my Emacs config into use-package. Most of that went straightforwardly into :init, :bind, :hook, etc. Custom variables moved to :custom, and custom faces moved to :custom-face. But this caused some faces to change, because custom-set-faces effectively replaces the face definition, while :custom-face overlaid it.
>
> If I understand the history, :custom-face initially called custom-set-faces, so it behaved identically to having custom-set-faces in custom.el. But this confusingly resulted in :custom-face definitions being written to custom.el as if the user had configured them through M-x customize. https://github.com/jwiegley/use-package/pull/1004 fixed that, unintentionally also changing the semantics of :custom-face.
>
> With my patch applied, :custom-face should be equivalent in behavior to custom-set-faces, but without the settings appearing as if they were user-set.

I think I've found one of source of confusion: `custom-set-faces' DOES
overlay/merge faces, but only for themed faces. For unthemed (default)
faces, it resets the entire face spec (as you describe).

> I don't know how this should interact with themes. Maybe the right approach there is to define a new personal theme and configure faces there instead of using :custom-face. Or maybe it is simplest to call face-spec-set explicitly from :config.

The former (custom theme) sounds like what use-package does with :custom
(it defines a use-package theme). Maybe just implement :custom-face the same way :custom is
implemented? I.e.:


    (defun use-package-handler/:custom-face (name _keyword args rest state)
      (use-package-concat
       (if (bound-and-true-p use-package-use-theme)
           `((let ((custom--inhibit-theme-enable nil))
               ;; Declare the theme here so use-package can be required inside
               ;; eval-and-compile without warnings about unknown theme.
               (unless (memq 'use-package custom-known-themes)
                 (deftheme use-package)
                 (enable-theme 'use-package)
                 (setq custom-enabled-themes (remq 'use-package custom-enabled-themes)))
               (custom-theme-set-faces
                'use-package
                ,@(mapcar
                   #'(lambda (def)
                       (let ((face (nth 0 def))
                             (spec (nth 1 def))
                             (comment (nth 2 def)))
                         (unless (and comment (stringp comment))
                           (setq comment (format "Customized with use-package %s" name)))
                         `(backquote (,face ,spec nil ,comment))))
                   args))))
         (mapcar
          #'(lambda (def)
              (let ((face (nth 0 def))
                    (spec (nth 1 def))
                    (comment (nth 2 def)))
                (unless (and comment (stringp comment))
                  (setq comment (format "Customized with use-package %s" name)))
                `(custom-set-faces (backquote (,face ,spec t ,comment)))))
          args))
       (use-package-process-keywords name rest state)))

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

From: Steven Allen <steven <at> stebalien.com>
To: Michael Shields <shields <at> msrl.com>, John Wiegley <johnw <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77928 <at> debbugs.gnu.org
Subject: Re: bug#77928: 31.0.50; ebcde0f90f6 (bug#77928) breaks :custom-face
 for themed faces
Date: Sun, 08 Jun 2025 15:46:38 -0700

Steven Allen <steven <at> stebalien.com> writes:
> The former (custom theme) sounds like what use-package does with :custom
> (it defines a use-package theme). Maybe just implement :custom-face the same way :custom is
> implemented? I.e.:
>
>
>     (defun use-package-handler/:custom-face (name _keyword args rest state)
>       (use-package-concat
>        (if (bound-and-true-p use-package-use-theme)
>            `((let ((custom--inhibit-theme-enable nil))
>                ;; Declare the theme here so use-package can be required inside
>                ;; eval-and-compile without warnings about unknown theme.
>                (unless (memq 'use-package custom-known-themes)
>                  (deftheme use-package)
>                  (enable-theme 'use-package)
>                  (setq custom-enabled-themes (remq 'use-package custom-enabled-themes)))
>                (custom-theme-set-faces
>                 'use-package
>                 ,@(mapcar
>                    #'(lambda (def)
>                        (let ((face (nth 0 def))
>                              (spec (nth 1 def))
>                              (comment (nth 2 def)))
>                          (unless (and comment (stringp comment))
>                            (setq comment (format "Customized with use-package %s" name)))
>                          `(backquote (,face ,spec nil ,comment))))
>                    args))))
>          (mapcar
>           #'(lambda (def)
>               (let ((face (nth 0 def))
>                     (spec (nth 1 def))
>                     (comment (nth 2 def)))
>                 (unless (and comment (stringp comment))
>                   (setq comment (format "Customized with use-package %s" name)))
>                 `(custom-set-faces (backquote (,face ,spec t ,comment)))))
>           args))
>        (use-package-process-keywords name rest state)))

This version has a bug: if a new theme is enabled (e.g., the user
switches themes at runtime), that new theme will take precedence over
this "use-package" theme. This differs from the behavior of
`custom-set-faces' which ALWAYS takes precedence.

If there's a way to use `custom-set-faces' with no custom themes, that
would be better.

I CAN fix (hack) this with a hook to reapply the theme as follows:

    (defun use-package--reapply-theme (theme)
      (unless (or (memq theme '(use-package user))
                  ;; prevents recursion
                  (memq 'use-package custom-enabled-themes))
        (enable-theme 'use-package)
        (setq custom-enabled-themes (remq 'use-package custom-enabled-themes))))
    (add-hook 'enable-theme-functions #'use-package--reapply-theme)

This mimic's the behavior of the "user" theme (the theme used by
`custom-set-faces') in `enable-theme' (reproduced below):

    (defun enable-theme (theme)
      ...
      (unless (eq theme 'user)
        (setq custom-enabled-themes
    	  (cons theme (remq theme custom-enabled-themes)))
        ;; Give the `user' theme the highest priority.
        (enable-theme 'user))
      ;; Allow callers to react to the enabling.
      (run-hook-with-args 'enable-theme-functions theme))

HOWEVER, it will cause the "user" theme to be applied twice (because
we're calling `enable-theme' from within `enable-theme'), which isn't
great.

Previous Next

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