Version 4.1.1 of package Modus-Themes has just been released in GNU ELPA. You can now find it in M-x list-packages RET.
Modus-Themes describes itself as: =============================================== Elegant, highly legible and customizable themes =============================================== More at https://elpa.gnu.org/packages/modus-themes.html ## Summary: # Modus themes for GNU Emacs IMAGES HERE: <https://protesilaos.com/emacs/modus-themes-pictures>. Highly accessible themes, conforming with the highest standard for colour contrast between background and foreground values (WCAG AAA). They also are optimised for users with red-green colour deficiency. The themes are very customisable and provide support for a very wide range of packages. Their manual is detailed so that new users can get started, while it also provides custom code for all sorts of more advanced customisations. ## Recent NEWS: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CHANGE LOG OF THE MODUS THEMES FOR GNU EMACS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ This document contains the release notes that are included in each tagged commit on the project's main git repository: <https://git.sr.ht/~protesilaos/modus-themes>. The newest release is at the top. Since the notes are meant to be in plain text format, I copy them verbatim. For further details, please consult these additional resources: Manual <https://protesilaos.com/emacs/modus-themes> Screenshots <https://protesilaos.com/emacs/modus-themes-pictures> 4.1.0 ═════ Recursive semantic colour mapping ───────────────────────────────── Version 4 of the Modus themes changed how all colour-related customisations are done. Instead of multiple user options with hard-coded stylistic presets, users have access to a comprehensive system of "named colours" and "semantic colour mappings". The former is an association between a name, like `blue-warmer', and a colour value such as `#3548cf'. While semantic colour mappings are associations between syntactic/interface constructs and named colours, such as what value level 2 headings have. When overriding the palette users can now define semantic colour mappings whose value is another such mapping. This recursion simplifies how multiple overrides are defined. The manual offers extensive guidance on the topic of palette overrides. There are many sections that include code samples that are ready for use. The addition of recursive semantic colour mappings solves a problem reported by Imran Khan on the mailing list where they were trying to do what made sense (recursion) but the old code did not permit as much: <https://lists.sr.ht/~protesilaos/modus-themes/%3Cb7ca4702162fd575593f8ded28d9a888.contact%40imrankhan.live%3E>. I was aware of that constraint from before the release of version 4.0.0 but was hesitant to implement recursion prior to getting some feedback on the new palette overriding feature. Also thanks to Christian Tietze for participating in that discussion on the mailing list. Extract an arbitrary colour from a given theme's palette ──────────────────────────────────────────────────────── I formalised the function `modus-themes-get-color-value' and documented it at length. It accepts a `COLOR' argument, which represents an entry in the palette (named colour or semantic colour value), as well as optional `OVERRIDES' and `THEME' arguments. When `OVERRIDES' is non-nil, `modus-themes-get-color-value' will read from the overrides, otherwise it will only consult the default palette value. The `THEME' argument specifies which theme's palette to use. In the absence of `THEME', the current one is used. I already had the "get colour" functionality internally, but was inspired to make it public after checking Sacha Chua's blog post "Making highlight-sexp follow modus-themes-toggle": <https://sachachua.com/blog/2023/01/making-highlight-sexp-follow-modus-themes-toggle/>. Sacha was using a private function from the themes, which would have been problematic if I would ever move things around. Remember to read the documentation of `modus-themes-list-colors'. That command shows a preview of the named colours. When called with a prefix argument (`C-u' by default), it shows a preview of the semantic colour mappings. Option to disable other themes while loading Modus ────────────────────────────────────────────────── In the past, we used to disable all other themes while loading a Modus theme. I revised this for version 4 because I learnt that some users use "themes" as bundles of arbitrary configurations. With the addition of the `modus-themes-disable-other-themes' user option, which is non-nil by default, I am restoring the old behaviour: when loading a Modus theme all other themes are disabled. … …
