Modus themes 2.1.0 for GNU Emacs
I will now take a break and then go for a brisk walk (writing a massive
changelog is no mean task). Once I return, I will prepare the patch for
master branch on emacs.git (currently this corresponds to Emacs
version 29). The
modus-themes package in GNU ELPA is a
package meaning that it fetches its contents from emacs.git, so expect
an update to trickle down shortly after my patch is merged.
Modus themes version 2.1.0
By Protesilaos Stavrou email@example.com on 2022-02-17
The present entry records the changes made to the project since the publication of version 2.0.0 on 2021-12-24. There have been more than 110 commits in the meantime (and this log is close to 5000 words).
All modifications of colour combinations mentioned herein are made in accordance with the primary accessibility objective of the themes for a minimum contrast ratio of 7:1 between background and foreground values in their given combination (the WCAG AAA standard for relative colour luminance). Edits also account for colour-coding that is optimised for the needs of users with red-green colour deficiency (deuteranopia).
To access the URL of the manual visit this web page: https://protesilaos.com/emacs/modus-themes. Or read it in the Emacs Info reader by evaluating this form:
(info "(modus-themes) Top")
The ‘modus-operandi’ and ‘modus-vivendi’ themes are built into Emacs-28 (next stable release) or later, and are available on GNU ELPA as well as other archives. Emacs-28 ships version 1.6.0, while the current ‘master’ branch (i.e. Emacs-29) and, by extension, GNU ELPA include the latest tagged release.
The following produce a buffer that previews the colour palette of the
given theme (
modus-themes-list-colorsprompts for a theme before producing the preview.
modus-themes-list-colors-currentuses the current Modus theme.
These commands are useful to anyone who wants to reference a named colour from the themes or copy a colour value, such as for the purposes of user-level customisation (as documented at length in the manual across several use-cases and with the inclusion of custom code).
The commands are not bound to any key.
modus-themes-markupvariable, which supersedes the now-deprecated
modus-themes-intense-markup. The new user option accepts a list of properties (symbols). It affects constructs such as Org’s
~code~, and macro (with three pairs of braces). By default, when this user option is either nil or an empty list, the affected constructs only have a foreground colour (e.g. Org verbatim is magenta). Properties that change this style are:
italicfor an added slant to the text.
boldfor a heavier weight.
backgroundto add a background colour.
intenseto amplify the colouration (especially of
As with all user options which accept a list of properties, the order of the symbols is no significant. In user configurations it may look like this:
(setq modus-themes-markup '(background intense bold))
[ Read the manual for bold and italic fonts. We do not hardcode a :weight or :slant, instead giving the user the option to set their own values. The defaults are what you would normally expect from “bold” and “italic”. ]
Thanks to Rudolf Adamkovič for reporting some problems with the old design in issue 274: https://gitlab.com/protesilaos/modus-themes/-/issues/274.
modus-themes-box-buttonswhich affects all pseudo graphical buttons, such as those found in Custom UI buffers or EWW web pages which include search forms and the like. The variable accepts a list of properties as its value. By default (nil or empty list), buttons have a grey background and the familiar 3D effect. Valid properties are:
flatto remove the 3D effect.
accentedto shift the colouration away from grey.
faintto reduce the overall colouration (e.g. grey becomes white).
variable-pitchto apply a proportionately spaced font.
underlineto draw a line instead of applying a 3D or flat box (particularly useful for those who use Emacs in a terminal emulator).
- The symbol of a font weight, such as
lightor any one among those included in the
modus-themes-weightsconstant (the underlying font family has to support the given weight).
- A number, expressed as a floating point (e.g. 0.9), which adjusts the height of the button’s text to that many times the base font size. The default height is the same as 1.0, though it need not be explicitly stated.
The order in which those symbols appear in the list is not significant. If
flatare both specified, the former takes precedence. In user init files the form may look like this:
(setq modus-themes-box-buttons '(variable-pitch flat semilight 0.9))
Thanks to Daniel Mendler for suggesting this user option and providing the relevant feedback in issue 282: https://gitlab.com/protesilaos/modus-themes/-/issues/282.
intensevariant. For example:
(setq modus-themes-mail-citations 'intense)
The default is a moderately coloured style. Other variants include
faintfor subtle colouration and
monochromefor an all-grey look.
modus-themes-completionoption and harmonised all the face specifications it governs. The variable now accepts a fourth stylistic variant in
super-opinionated: it is like the
opinionatedone though some details are even more pronounced. Other noteworthy items:
[ Remember to read the doc string of
modus-themes-completions, which explains the grouping of the completion UIs. ]
(setq modus-themes-completions 'moderate)style is more-or-less the same across all completion UIs. The highlight applied to the current line is a bespoke shade of blue, the characters are less saturated than before and their hues are different, though the overall effect should still feel “sufficiently colourful, but not overdone”.
(setq modus-themes-completions nil)is the same as before. However:
The current line in Ivy now uses a shade of blue that is specific to completion UIs instead of an intense cyan background. This is for theme-wide consistency.
Helm’s current line has the same bespoke blue for its current line instead of another shade of blue it was using before.
(setq modus-themes-completions 'opinionated)should be the same as before, notwithstanding the aforementioned tweaks to Ivy/Helm.
(setq modus-themes-completions 'super-opinionated)for Icomplete, Vertico, Selectrum, Mct uses the same blue for the current line as is the default of Ivy and Helm.
The relevant private helper functions were rewritten.
We declare a few faces to help streamline certain styles.
Ivy action keys now inherit from
modus-themes-key-binding. We generally try to make all keys look the same, except when that would be detrimental to the usability of the given context/interface.
Some Ivy faces are simplified or otherwise tweaked to fit in with the rest of the theme.
Thanks to Rudolf Adamkovič for the feedback about Vertico in issues 214 and 278 which prompted me to review all completion UIs:
Adjusted the applicable hues in some
modus-themes-syntaxvariants. In particular:
- The strings’ hue has more hints of blue when
green-stringsproperty. Such as:
(setq modus-themes-syntax '(green-strings)) (setq modus-themes-syntax '(alt-syntax green-strings)) (setq modus-themes-syntax '(alt-syntax green-strings faint)) (setq modus-themes-syntax '(alt-syntax green-strings faint yellow-comments))
- Strings are more orange/yellow than red when
alt-syntaxproperty but NOT the
green-strings. For example:
(setq modus-themes-syntax '(alt-syntax)) (setq modus-themes-syntax '(alt-syntax yellow-comments)) (setq modus-themes-syntax '(alt-syntax yellow-comments faint))
- Backslashes for regexp constructs are coloured appropriately to look distinct from the rest of the string and from the escaped construct in all cases.
- The strings’ hue has more hints of blue when
Removed background colours from the the default style of Org block delimiters.
As I explained in Emacs bug#52587, Org has code that overrides themes which prefer not to extend the block delimiter faces to the edge of the window (as we would like to do by default). This practically means that we cannot have backgrounds for those lines and keep them limited to the stretch of area covered by their text.
As such, the default for Org block delimiter lines now is a gray foreground with no distinct background colour. The user option
modus-themes-org-blocksprovides “blocky” alternatives that use background colours—those extend to the edge of the window.
Deleted the compatibility layer for all user options that used to accept symbols in the past but now expect a list of symbols. The manual contains a snippet with all customisation options for those who do not want to read all the relevant doc strings. Evaluate this:
(info "(modus-themes) Customization Options")
The original plan was to remove those during the transition to version 2.0.0 (about a month ago) though I changed my mind thinking they would not pose a longer-term problem.
New information by Mark Bestley in issue 272 shows that this kind of complexity can lead to errors: https://gitlab.com/protesilaos/modus-themes/-/issues/272#note_826725412.
So it is better to keep things simple and ask users to configure all user options based on the up-to-date documentation.
Also thanks to Saša Janiška for the feedback in issue 272.
New packages, faces, or face groups
child-frame-borderface (Emacs 28).
citarpackage. Thanks to Rudolf Adamkovič for the feedback in issue 280: https://gitlab.com/protesilaos/modus-themes/-/issues/280.
elisp-shorthand-font-lock-face(Emacs 29). Read the manual by evaluating:
(info "(elisp) Shorthands")
ement(ement.el) Matrix client, though it is not listed in any archive yet: https://github.com/alphapapa/ement.el.
Thanks to Samuel Culpepper for the feedback in issue 279: https://gitlab.com/protesilaos/modus-themes/-/issues/279.
Also check the Ement issue tracker on the matter: https://github.com/alphapapa/ement.el/issues/53.
menuface (built-in) which is used in the menu-bar when Emacs runs without a graphical toolkit.
pgtk-im-0face (Emacs 29). This is shown as a single-character-long block when you type the Compose key followed by the composable characters.
pyim(an input method for CJK characters). Thanks to Yuanchen Xie for the contribution in merge request 57: https://gitlab.com/protesilaos/modus-themes/-/merge_requests/57. The patch is small and is thus excluded from the requirement for copyright assignment to the FSF (remember that the themes are built into Emacs and any major contribution needs such copyright assignment—read the relevant entry in the themes’ manual).
slypackages. Thanks to John Haman for the feedback which was done via email due to some problems with the web UI on GitLab (this information is shared with permission). Please note that I am not familiar with Common Lisp and could not test these thoroughly. Any mistakes or omissions are my own.
Concerning the web UI, there is a fully functional mirror of the themes on GitHub, while email is always an option. Use whatever works for you to report an issue or send a patch.
textsecpackage (Emacs 29).
New indirectly supported packages
These inherit from base faces and look good enough already or use appropriate colours from the Modus themes:
Changes to supported faces or face groups
Stopped making key bindings look like boxes. We revert to the old style we were using before the introduction of the
help-key-bindingface (Emacs 28).
By default Emacs 28 or higher will render all key bindings it identifies with a box around them. The idea is to make them look like keys on a keyboard, which I never really liked because without generous padding you get a very tight space between the character and the box’s borders which can look weird at small point sizes (Emacs faces do not have padding in the same way CSS does).
I tried following the default style for a few months and have concluded that it is not good enough for our purposes (my preferences notwithstanding):
The box attribute does not work in terminal emulators. This means that keys only get a subtle grey background and the default foreground, which can be hard to make them stand out from their surrounding text if the font height is small and/or the keybinding is short (e.g. a single character).
The box and grey background combination limits our options when we need to colour-code different types of keys. For example, the
which-keypackage can show TAB as T and applies to it a different face to make the distinction obvious. In that case, the presence of the tight box makes the use of a bold weight inappropriate: the character and the box’s borders seem to overlap. While the grey background limits our choice of colour as, for instance, yellow never looks good against it. Same principle for interfaces that can have colour-coded keys like
hydra, where we lose much-needed flexibility.
Adjusted the brightness of the
which-key-special-key-face. This is the face that applies to special keys. For example:
(setq which-key-special-keys '("SPC" "TAB" "RET" "ESC" "DEL"))
transientfaces which are supposed to be de-emphasise certain elements inherit the
shadowface. This is an implicit customisation option, as it allows the user to adjust the foreground value of all “less important” constructs simply by changing the
transient-purpleface (these are like the colour-coding of
transient-valuefaces to make things look a bit more consistent with the other transient faces. This is to avoid potential conflicts with the highlighted key bindings, especially when transient uses hydra-style colour-coded keys.
Applied the same metaphors for key bindings to
embarkpackage). They inherit the
modus-themes-key-bindingwhen possible. The only exception is with
(setq modus-themes-completions nil)where conflicts may arise between the key’s style and matching characters of the ongoing completion session.
Thanks to Rudolf Adamkovič for pointing out the inconsistency in issue 278: https://gitlab.com/protesilaos/modus-themes/-/issues/278.
Refrained from treating LaTeX sections as headings. This is because unlike Org/Outline/Markdown Latex is basically source code, so the sectioning does not work the same way it does for those lightweight markup/outlining modes.
Furthermore, font-latex.el defines
font-latex-fontify-sectioningwhich can be used to control the scale of those sections. It makes sense for the themes to not interfere with that design and just allow users to customise things uniformly regardless of the active theme.
Thanks to Gustavo Barros for the detailed feedback in issue 265: https://gitlab.com/protesilaos/modus-themes/-/issues/265.
Reviewed the hues of
all-the-iconsand related packages.
Applied the correct style to
info-menu-header, meaning that it now only uses a bold weight as it is not a real heading, instead of being affected by the user option
telega-entity-type-spoilerface. Thanks to bit9tream for informing me about it in issue 271: https://gitlab.com/protesilaos/modus-themes/-/issues/271. The conclusion:
Tricky though perhaps dull
I understand this is not an interesting topic and it probably is too difficult to relate to the various data points without visualising them and comparing the before and after states. Furthermore, data can be deceptive and I have always maintained that theme development stands at the intersection of science and art (at least for the purposes of conforming with the rigorous accessibility standards of the Modus themes).
That granted, I wanted to shed light on the “behind the scenes” work that is not immediately obvious when one checks a diff that introduces some seemingly trivial tweaks like
Tweaked the hues of all graph colours, which are used in the
org-habittable. The changes are subtle and should improve the overall usability of the graph. For the technicalities, read: https://protesilaos.com/codelog/2022-01-02-review-modus-themes-org-habit-colours/.
Also thanks to Rudolf Adamkovič for reporting the problem with white text on yellow background in issue 270: https://gitlab.com/protesilaos/modus-themes/-/issues/270.
markdown-highlighting-face. This is the face used for text in between double equals signs when the user option
Amplified the overall colouration of Eldoc’s current argument. It is a yellow foreground with a tinted background. The blue foreground which was applied before could be hard to tell apart in some cases, especially because it is a common colour that is used elsewhere in the themes. Whereas the warmer hues are easier to discern, especially while relying only on peripheral vision.
Thanks to Rudolf Adamkovič for the feedback in issue 275: https://gitlab.com/protesilaos/modus-themes/-/issues/275.
Instructed Geiser to use the same style for its argument as Eldoc (edited the faces
keycast-keyface work when
modus-themes-mode-linehas a padding value (read the latter doc string or consult the manual).
magitfaces for bisect, reflog, sequence, and signature views. They get a bold weight and, where appropriate, are made to comply with the
modus-theems-deueteranopiaoption (meaning that greens turn into blues).
elfeedtags from a shade of cyan to magenta, in the interest of theme-wide consistency but also to make them easier to tell apart from the name of the feed. Also updated the faces used in the header-line to look better in context.
Removed the hardcoded
:slant italicfrom the
italicface, which is consistent with how we do not hardcode
:weight boldin the
Such a design allows users to configure those faces and have the desired slant/weight (and even font family) apply consistently throughout the theme. Read the manual for further details: https://protesilaos.com/emacs/modus-themes#h:2793a224-2109-4f61-a106-721c57c01375.
Thanks to user derek-upham for pointing out the inconsistency in issue 21 over at the GitHub mirror: https://github.com/protesilaos/modus-themes/issues/21.
Improved the styles that apply to compilation buffers and related. The overarching intent was to reduce the excess colouration, without upsetting expectations and affecting the overall presentation.
Thanks to Rudolf Adamkovič for the feedback in issue 277: https://gitlab.com/protesilaos/modus-themes/-/issues/277.
Note that compilation buffers apply an underline by default. The manual explains how to change that: https://protesilaos.com/emacs/modus-themes#h:420f5a33-c7a9-4112-9b04-eaf2cbad96bd.
Ensured a consistent style for the
highlightface across all contexts (typically used for mouse hover effects). The mode line has an exception when its style includes an accented background (per
Thanks to Rudolf Adamkovič for the feedback in issue 214: https://gitlab.com/protesilaos/modus-themes/-/issues/214.
Changed the foreground of
mode-line-emphasisfrom blue to purple, in order to avoid potential (albeit unlikely) confusion with other indicators.
womanforeground value of the bold constructs and tweaked other faces to avoid potential inconsistencies. Thanks to Daniel Mendler for the feedback: https://gitlab.com/protesilaos/modus-themes/-/commit/8080eb1c6c0020ba82e8abaa933d6686327bc616#note_841424489.
Removed certain exaggerations from widgets as seen in the Custom UI and EWW. Specifically:
widget-fielddoes not need to
:extend, as that typically does not look good.
custom-stategets a warmer colour to convey its message more effectively.
eww-form-textno longer uses a
:boxbecause that breaks when the widget occupies more than one line.
eww-form-textareacan now inherit from
Thanks to Daniel Mendler for the feedback on the style of those faces in issue 284: https://gitlab.com/protesilaos/modus-themes/-/issues/284.
Clarified the wording of
shrfonts, which affect
ement, and possibly others.
Wrote section on custom Org emphasis faces. It includes code samples.
Answered a Frequently Asked Question on whether the Modus themes are “colour schemes”—they are not and it is important to understand why.
Addressed another Frequently Asked Question about porting the themes to other platforms or editors. Relevant blog posts which explain how complex the issue is and why porting requires the same attention to detail as this project:
Improved the sample code in the section about the backdrop of PDF files while using
pdf-tools. Thanks to Utkarsh Singh for the patch, which was sent via email.
Provided sample code on an alternative style for Ediff.
There was a discussion with Philip Kaludercic in issue 273 about making this a defcustom: https://gitlab.com/protesilaos/modus-themes/-/issues/273.
I first entertained the notion and did set up a branch for testing purposes. However, I ultimately decided that such a course of action would establish a bad precedent because then every conceivable stylistic tweak could, in principle, become a user option. Furthermore, the potential defcustom would introduce too much complexity as Ediff would have to continue to behave as other diffs (per
modus-themes-diffs) if the user did not want the alternative style.
As such, documenting how a user can achieve this is the right choice.
Fixed internal link in the manual. Thanks to Rudolf Adamkovič for reporting the problem in issue 277: https://gitlab.com/protesilaos/modus-themes/-/issues/277.
Covered workaround for improving the accuracy of colour reproduction in terminal emulators. The results are still not as good as the graphical version of Emacs, though they are considerably better than before. Thanks to gitrj95’s issue 18 at the GitHub mirror, which prompted me to research this topic: https://github.com/protesilaos/modus-themes/issues/18.
Helped report a bug in the PGTK build of Emacs where a new emacsclient window with the
modus-vivendiface would not show the cursor: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53073. Thanks to contributed to the discussion on issue 7 over at the GitHub mirror: https://github.com/protesilaos/modus-themes/issues/7
Shifted the hue of the intense
hl-linefrom a grey-cyan to a more vivid blue by reducing the relative contribution of the green channel of light.
The change affects these styles:
(setq modus-themes-hl-line '(accented intense)) (setq modus-themes-hl-line '(accented intense underline))
Thanks to Rudolf Adamkovič for suggesting a more vivid colour in issue 214: https://gitlab.com/protesilaos/modus-themes/-/issues/214.
I wanted to increase its distance relative to the main background, just to be sure that it is easier to spot. This is achieved by moving the hueness from the yellow to the magenta side of the spectrum.
Overall, the change is subtle and has no major impact on the contrast ratio relative to the main background and foreground (we need to consider both due to the specifics of show-paren-mode (and related)).
The results (#5f362f is the old, #6f3355 the new):
| | #000000 | #ffffff | #000000 | #ffffff | |---------+---------+---------+---------+---------| | #5f362f | 2.06 | 10.22 | 37904 | 333060 | | #6f3355 | 2.28 | 9.21 | 58282 | 291037 |
The TBLFM formula for this table (org-mode notation):
$2='(Λ $1 @1$2);%.2f :: $3='(Λ $1 @1$3);%.2f :: $4='(Δ $1 @1$4) :: $5='(Δ $1 @1$5)
The Greek letters mean:
(defalias 'Λ #'modus-themes-contrast) (defalias 'Δ #'color-distance)
Expanded the “special” subset of the palette with faint variants of the four backgrounds. These are reserved for special circumstances, as the name implies. Below are the contrast values (see
Modus Operandi main accept colours against faint special backgrounds: | | #f0f1ff | #ebf5eb | #fef2ea | #faeff9 | |---------+---------+---------+---------+---------| | #a60000 | 7.15 | 7.17 | 7.29 | 7.16 | | #972500 | 7.26 | 7.28 | 7.40 | 7.28 | | #a0132f | 7.13 | 7.15 | 7.27 | 7.14 | | #7f1010 | 9.44 | 9.47 | 9.63 | 9.47 | | #702f00 | 8.94 | 8.97 | 9.12 | 8.96 | | #7f002f | 9.64 | 9.67 | 9.83 | 9.66 | | #005e00 | 7.20 | 7.23 | 7.34 | 7.22 | | #315b00 | 7.13 | 7.15 | 7.27 | 7.15 | | #145c33 | 7.18 | 7.20 | 7.32 | 7.20 | | #104410 | 10.09 | 10.12 | 10.29 | 10.12 | | #30440f | 9.56 | 9.59 | 9.75 | 9.58 | | #0f443f | 9.76 | 9.79 | 9.96 | 9.79 | | #813e00 | 7.14 | 7.17 | 7.28 | 7.16 | | #70480f | 7.14 | 7.17 | 7.28 | 7.16 | | #863927 | 7.13 | 7.15 | 7.27 | 7.15 | | #5f4400 | 8.10 | 8.12 | 8.26 | 8.12 | | #5d5000 | 7.17 | 7.19 | 7.31 | 7.19 | | #5e3a20 | 8.91 | 8.94 | 9.09 | 8.93 | | #0031a9 | 9.31 | 9.34 | 9.49 | 9.33 | | #2544bb | 7.14 | 7.16 | 7.28 | 7.16 | | #0000c0 | 10.64 | 10.67 | 10.85 | 10.66 | | #003497 | 9.66 | 9.70 | 9.86 | 9.69 | | #0f3d8c | 9.06 | 9.09 | 9.24 | 9.09 | | #001087 | 13.15 | 13.20 | 13.42 | 13.19 | | #721045 | 9.99 | 10.02 | 10.19 | 10.01 | | #8f0075 | 7.72 | 7.75 | 7.88 | 7.74 | | #5317ac | 8.98 | 9.01 | 9.16 | 9.00 | | #752f50 | 8.22 | 8.25 | 8.38 | 8.24 | | #7b206f | 8.22 | 8.25 | 8.38 | 8.24 | | #55348e | 8.26 | 8.29 | 8.42 | 8.28 | | #00538b | 7.18 | 7.20 | 7.32 | 7.19 | | #30517f | 7.18 | 7.20 | 7.32 | 7.20 | | #005a5f | 7.13 | 7.15 | 7.27 | 7.15 | | #005077 | 7.76 | 7.79 | 7.91 | 7.78 | | #354f6f | 7.49 | 7.52 | 7.64 | 7.51 | | #125458 | 7.69 | 7.72 | 7.85 | 7.71 | Modus Vivendi main accept colours against faint special backgrounds: | | #0e183a | #001f1a | #241613 | #251232 | |---------+---------+---------+---------+---------| | #ff8059 | 7.01 | 7.01 | 7.07 | 7.00 | | #ef8b50 | 7.01 | 7.00 | 7.07 | 7.00 | | #ff9077 | 7.85 | 7.85 | 7.93 | 7.85 | | #ffa0a0 | 8.91 | 8.91 | 9.00 | 8.91 | | #f5aa80 | 9.04 | 9.04 | 9.13 | 9.04 | | #ff9fbf | 9.06 | 9.05 | 9.14 | 9.05 | | #44bc44 | 7.04 | 7.04 | 7.11 | 7.04 | | #70b900 | 7.13 | 7.13 | 7.20 | 7.12 | | #00c06f | 7.24 | 7.24 | 7.31 | 7.24 | | #78bf78 | 7.87 | 7.86 | 7.94 | 7.86 | | #99b56f | 7.60 | 7.59 | 7.67 | 7.59 | | #88bf99 | 8.23 | 8.22 | 8.30 | 8.22 | | #d0bc00 | 8.98 | 8.98 | 9.07 | 8.98 | | #c0c530 | 9.31 | 9.31 | 9.40 | 9.30 | | #d3b55f | 8.71 | 8.71 | 8.79 | 8.71 | | #d2b580 | 8.81 | 8.80 | 8.89 | 8.80 | | #cabf77 | 9.28 | 9.27 | 9.36 | 9.27 | | #d0ba95 | 9.20 | 9.20 | 9.29 | 9.20 | | #2fafff | 7.18 | 7.18 | 7.25 | 7.18 | | #79a8ff | 7.32 | 7.32 | 7.39 | 7.31 | | #00bcff | 7.96 | 7.96 | 8.04 | 7.96 | | #82b0ec | 7.74 | 7.74 | 7.81 | 7.74 | | #a0acef | 7.97 | 7.96 | 8.04 | 7.96 | | #80b2f0 | 7.89 | 7.88 | 7.96 | 7.88 | | #feacd0 | 9.94 | 9.93 | 10.03 | 9.93 | | #f78fe7 | 8.29 | 8.29 | 8.37 | 8.29 | | #b6a0ff | 7.82 | 7.81 | 7.89 | 7.81 | | #e0b2d6 | 9.51 | 9.50 | 9.60 | 9.50 | | #ef9fe4 | 8.88 | 8.88 | 8.96 | 8.87 | | #cfa6ff | 8.72 | 8.71 | 8.80 | 8.71 | | #00d3d0 | 9.28 | 9.27 | 9.36 | 9.27 | | #4ae2f0 | 11.09 | 11.09 | 11.20 | 11.09 | | #6ae4b9 | 11.08 | 11.07 | 11.18 | 11.07 | | #90c4ed | 9.34 | 9.34 | 9.43 | 9.33 | | #a0bfdf | 9.10 | 9.09 | 9.18 | 9.09 | | #a4d0bb | 10.18 | 10.17 | 10.27 | 10.17 |
Add docs on color overrides through blending. Thanks to Alex Griffin for the contribution in issue 269 and the subsequent patch in merge request 56 (the patch is exempt from copyright assignment):
Fixed typo in the
:groupvalue of some faces defined in modus-themes.el. Thanks to Gustavo Barros for reporting it in issue 266: https://gitlab.com/protesilaos/modus-themes/-/issues/266
Updated copyright statement in all .el files to use the same wording as all other files that are built into Emacs.
Made all sorts of tweaks and refinements to doc strings and nodes in the manual.
Thanks again to everyone involved! This has been yet another cycle of intense work which further iterated on an already solid base.