diff options
| author | Craig Jennings <c@cjennings.net> | 2026-05-25 11:54:39 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-05-25 11:54:39 -0500 |
| commit | 32cfe216b4f5917b1a979e0372edf9b8f1ab62ea (patch) | |
| tree | 7fe70b4d8a120dd8402d19faa3546f388d8e17cf /tests/test-custom-ordering-unarrayify.el | |
| parent | 56da3d940b26a51102bce39b3b82dfbbc2b391fd (diff) | |
| download | dotemacs-32cfe216b4f5917b1a979e0372edf9b8f1ab62ea.tar.gz dotemacs-32cfe216b4f5917b1a979e0372edf9b8f1ab62ea.zip | |
fix(theme): register dupre faces so org status colors are themed
The dupre theme defined its own faces (dupre-accent, the headings, and the org status faces) only through custom-theme-set-faces, never defface. That leaves them unregistered, so they render through :inherit but silently fail when applied directly as a text property. org-todo-keyword-faces and org-priority-faces apply faces that way, so the org keyword and priority colors never showed as dupre tones.
I added a defface registration block to dupre-faces.el for all of dupre's own faces, so they're real faces. The theme still sets their colors. Then I pointed org-todo-keyword-faces and org-priority-faces (in org-config.el) at named dupre-org-* faces, each the closest palette color to its former hard-coded name, and gave each a dimmed variant that auto-dim-config.el swaps in for unfocused windows. A keyword in a dimmed window now shows a darker shade of its own color rather than flat gray or full brightness.
A regression test asserts dupre's faces stay registered, since that was the latent bug behind all of this.
Diffstat (limited to 'tests/test-custom-ordering-unarrayify.el')
0 files changed, 0 insertions, 0 deletions
