My Emacs configuration https://git.cjennings.net/dotemacs/atom?h=main 2026-05-26T18:15:59+00:00 2026-05-26T18:15:59+00:00 Craig Jennings c@cjennings.net 2026-05-26T18:15:59+00:00 urn:sha1:db83a4975be50b5c579b0a075acd952f8135a73f org-level-1..4 inherit dupre-heading-1..4, which set :weight bold, so org headings rendered bold. I overrode the weight to normal on the org-level faces themselves rather than on dupre-heading-*, so the info-manual, markdown, and shr headings that also inherit those faces keep their bold. I also dropped the bold from org-document-title for consistency. 2026-05-26T17:47:30+00:00 Craig Jennings c@cjennings.net 2026-05-26T17:47:30+00:00 urn:sha1:f23ca905740411f324c2d1fef9f9ffba4b7b7424 org-block-begin-line and org-block-end-line carried a bg+1 (#252321) background, so the #+begin_src and #+end_src lines showed a lighter box that matched neither the block body nor the normal background. I pointed both at the theme background so the delimiter lines sit flush, keeping their gray foreground. 2026-05-26T17:11:20+00:00 Craig Jennings c@cjennings.net 2026-05-26T17:11:20+00:00 urn:sha1:8944d69ece46a6f0b4bb9c578e49afaa4f25c86f A level-2 heading's whole line carries org-level-2 (height 157). org layers that level face onto a bare TODO keyword, but drops it when the heading has a priority cookie, so the keyword fell back to the body height (143). The same keyword rendered at 157 without a cookie and 143 with one, which read as inconsistent keyword sizes across the Linear and todo views. I gave org-todo, org-done, and the dupre-org-* keyword and priority faces an explicit :height of 143 so they no longer float with the heading face. The height is absolute on purpose. A float would re-inherit the level height inside the face list and bring the inconsistency back. Keywords now render at the body height everywhere, a step down from the heading title. 2026-05-26T14:39:06+00:00 Craig Jennings c@cjennings.net 2026-05-26T14:39:06+00:00 urn:sha1:1c7a72111ef24d1c6059061608edd2b094436fe0 org-todo was intense-red (#ff2a00), the brightest red in the palette. Every TODO-state keyword that isn't in org-todo-keyword-faces falls back to org-todo. So the Linear states (IN-PROGRESS, BACKLOG-PRIORITIZED, and the rest) all rendered in that hot red, and the whole view shouted. I moved org-todo to red-1 (#a7502d) and org-warning to red (#d47c59). They're distinct now, so an overdue deadline reads a shade warmer than a plain keyword. intense-red stays reserved for the FAILED face. 2026-05-26T12:47:03+00:00 Craig Jennings c@cjennings.net 2026-05-26T12:47:03+00:00 urn:sha1:877a7cbc87abe1df4b5d881f204c593141ca8c88 The previous #151311 was already the palette's darkest entry. #0d0b0a is about 40% darker again. Both bg and bg+0 move together because bg+0 feeds hl-line, which should stay equal to the background. 2026-05-25T16:54:39+00:00 Craig Jennings c@cjennings.net 2026-05-25T16:54:39+00:00 urn:sha1:32cfe216b4f5917b1a979e0372edf9b8f1ab62ea 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. 2026-05-25T14:25:32+00:00 Craig Jennings c@cjennings.net 2026-05-25T14:25:32+00:00 urn:sha1:56da3d940b26a51102bce39b3b82dfbbc2b391fd I added auto-dim-config, a module that loads my local auto-dim-other-buffers fork and dims windows that don't have focus so the selected window stands out. A non-selected window drops to a pure-black background with faded gray text. The dimmed faces live in the dupre theme (themes/dupre-faces.el) so they track theme switches, and the module remaps default, the font-lock faces, and org-block onto them so syntax-highlighted code fades too rather than staying lit. Fringe is left out because dimming it forces a full-frame refresh that flickers on this non-pgtk build. dim-on-focus-out is nil, so tabbing to a browser or terminal on Hyprland doesn't dim the whole frame. vterm and agent windows don't dim either, because the terminal paints its own per-cell colors past the face remap. I'm keeping that, since the agent's output stays readable while I work in code on the other side. The module loads after the theme, carries a load-graph header, joins the header-contract allowlist, and the inventory moves to 103 of 103 classified. 2026-05-22T23:15:00+00:00 Craig Jennings c@cjennings.net 2026-05-22T23:15:00+00:00 urn:sha1:11e3a27e752e845e583348c497b2c5b0208c8a52 The banner subtitle sat left of center because dashboard-banner-title-offset was 5, which over-shifts. I dropped it to 3, which lines the subtitle up under the banner image. The navigator and the recentf/project/bookmark list rendered in the default near-white. I set dashboard-items-face to steel+2 so they pick up a theme color, and the section headers stay blue via dashboard-heading. The navigator and the items share dashboard-items-face, because the navigator is drawn with a dashboard-items-face overlay that wins over its per-button dashboard-navigator face, so they take one color by design here. 2026-05-22T22:03:24+00:00 Craig Jennings c@cjennings.net 2026-05-22T22:03:24+00:00 urn:sha1:ec42e0f6c7e9452d79898a096eca2710b23a9d60 The committed palette PNG had drifted from the theme. It labeled steel as "cyan", invented magenta colors the palette never had, and left out blue+2. There was no generator, so the preview and the source diverged silently. I added gen-palette-preview.py, which parses the (name "#hex") pairs straight out of dupre-palette.el and emits the preview HTML grouped one row per color family. I regenerated the HTML and the PNG from it, so all 32 colors show with square swatches at 2x, columns aligned, and nothing drifts from palette.el again. 2026-01-27T13:00:23+00:00 Craig Jennings c@cjennings.net 2026-01-27T13:00:23+00:00 urn:sha1:98aca11d7e385d146e5e49be590b75e575a685ec Use :vc to install org-drill from GitHub instead of :load-path to local clone. Add dupre color palette reference image.