| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | refactor(themes): retire dupre, fall back to modus-vivendi | Craig Jennings | 13 days | 1 | -7/+5 |
| | | | | | WIP, the theme-studio export, is the active theme. dupre was only the fallback and a structural reference. Move the fallback to the built-in modus-vivendi, guaranteed present everywhere this config loads. Delete the three dupre files plus its test and palette assets, and fix the stale comments that pointed at dupre-faces.el for the auto-dim and org-keyword faces (those moved to org-faces-config.el). Repoint the dupre-clear-theme spec's palette reference to git history. | ||||
| * | feat(ui-theme): default the theme fallback to bundled dupre | Craig Jennings | 2026-05-25 | 1 | -0/+10 |
| | | | | | | | The fallback kicks in when persist/emacs-theme is missing — a fresh machine, or one that's never saved a theme. It was modus-vivendi, which ships with Emacs but has none of the dimming colors this config chooses, so an unconfigured machine looked and dimmed differently from a configured one. I hit exactly that on a second box this week. dupre is bundled in themes/ and carries those colors, and it loads wherever this config does, so it's the better default. I added a regression test asserting the default is dupre; its loadability is already covered by test-dupre-theme.el. The docstring no longer claims the fallback must be a built-in theme, since dupre isn't one. | ||||
| * | test(ui-theme): cover switch-themes, save-to-file, get-active-name | Craig Jennings | 2026-05-14 | 1 | -0/+110 |
