GNU bug report logs -
#77928
[PATCH] use-package :custom-face is meant to behave like custom-set-face
Previous Next
Reported by: Michael Shields <shields <at> msrl.com>
Date: Sat, 19 Apr 2025 20:42:02 UTC
Severity: normal
Tags: patch
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #55 received at 77928 <at> debbugs.gnu.org (full text, mbox):
> 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?
This bug report was last modified 42 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.