emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

custom-theme-set-faces/face inheritance and delayed face initialization


From: Yuri D'Elia
Subject: custom-theme-set-faces/face inheritance and delayed face initialization
Date: Tue, 04 Jan 2022 15:50:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Some thoughts regarding the delayed face calculations, themes and custom
code following...

I'm using a 3rd-party theme which is using custom-theme-set-faces to
define the various faces. Is it intended that custom-theme-set-faces
replaces the entire face definition?

This doesn't play too well with the recent changes of the mode-line,
mode-line-active, mode-line-inactive definitions: themes will reset the
face inheritance, which is both good and bad. Good as the theme will
ignore any upstream change. Bad because I cannot change the base
mode-line face to apply changes to both active/inactive faces as I would
expect.

For a concrete example, I ended up liking a lot using variable-pitch on
the mode-line: I never use the buttons, and there's nothing in there
that needs alignment, so I'm using a condensed font there to get more
character-real-estateā„¢ for buffer names.

So after the change has been reverted, I modified manually the base
mode-line face to inherit from variable-pitch. I somehow expected themes
to follow this inheritance, but the theme is redefining the face and
thus wipes the base face inheritance chain.

This becomes an issue with the theme and custom system hooking into
after-make-frame-functions: any face change done manually is lost unless
it's hooked and run repeatedly after the theme has been set. New frames
would revert to the original theme definition otherwise.

IMHO this is not nice, as it's quite fragile: you need to ensure that a
theme is loaded first, and ensure all the changes repeat in
after-make-frame-functions _after_ the theme/custom interface takes
place.

Using customize would be an option which seems to be supported, however
I don't like using the customization interface in general: it's parallel
to my elisp code, which is where I want everything to be. I support
customization in the packages I write for easy discovery, but I never
use it myself (and I wonder how common that is).

So I was looking at the possibility to _update_ the face in the theme by
using custom-theme-set-faces directly, so that my changes persist and
get automatically performed after each frame is changed. This seems to
be the only good way to persist changes, as well as automatically
delaying font family changes until the frame is made. That would _also_
allegedly play correctly with customize.

But I don't see a convenient way to do that: it looks like I could use
custom-theme-set-faces to update the theme by fetching the current
definition first using custom-face-attributes-get.

Is anybody doing this?
Is there a better way?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]