Just published version 0.13.0 of the Modus themes. The release notes are reproduced below. This is the largest release to date and also the first one since the themes were incorporated in upstream Emacs.

Packages may take a while to get the update, so please be patient. Contact me in case something is amiss.


Modus Operandi and Modus Vivendi version 0.13.0

By Protesilaos Stavrou info@protesilaos.com on 2020-10-08

This entry documents the changes since version 0.12.0 (2020-08-26). There have been around 150 commits in the meantime, making this the largest release to date (though sheer volume should not be conflated with quality, of which there is plenty).

As always, everything described herein conforms with the overarching accessibility objective of the themes for a minimum contrast ratio of 7:1 between background and foreground values in their given combinations (conformance with the WCAG AAA standard).

Overview

  1. There is a new Info manual that documents the customisation options as well as every other piece of information pertinent to the themes. You will find it in the Info pages inside of Emacs. Or browse it online: https://protesilaos.com/emacs/modus-themes.

  2. New customisation options grant users more power to further adapt the active theme to their preferences.

  3. Extended coverage for even more faces and face groups, adding to the already comprehensive list of directly supported ones.

  4. Lots of tweaks to improve the use of colour and avoid exaggerations (well, “exaggerations” is relative, since the prior state was already carefully designed).

  5. A new page hosts all pictures that demo the themes across a wide range of scenaria: https://protesilaos.com/emacs/modus-themes-pictures.

  6. Similarly, the change log also has its own dedicated web page: https://protesilaos.com/emacs/modus-themes-changelog.

New customisation options

Note that all customisation options are documented at length in the new Info manual. What is offered here is not necessarily exhaustive.

Diff styles

Symbol names (“choice” type):

Possible values:

  1. nil (default)
  2. desaturated
  3. fg-only

DEPRECATED (“boolean” type):

This option supersedes older ones while retaining their functionality.

The default remains unaltered, meaning that the diffs will use fairly prominent colour-coded combinations for the various elements (e.g. green text on an unambiguously green backdrop).

A desatured value will tone down the default aesthetic, giving a less vibrant feel.

While fg-only removes almost all coloured backgrounds, opting to apply colour only to the relevant text (this was the case with the now-deprecated options). There are some exceptions, like word-wise or “refined” diffs, which still use coloured backgrounds to convey their meaning.

Modeline styles

Symbol names (“choice” type):

Possible values:

  1. nil (default)
  2. 3d
  3. moody

DEPRECATED (“boolean” type):

The default modeline continues to be a two-dimensional rectangle with a border around it. Active and inactive modelines use different colour combinations for their main background and foreground.

Option 3d produces an effect similar to what you get in a generic Emacs session, where the active modeline has a pseudo three-dimensional effect applied to it. This option offers the same functionality as that of the deprecated variables.

Option moody is designed specifically for use with the Moody library, though it can also be used without it. Instead of implementing a box effect, it applies an overline and underline instead, while also toning down the inactive modeline.

Thanks to Nicolas De Jaeghere for the feedback and code samples in issue 80: https://gitlab.com/protesilaos/modus-themes/-/issues/80

Headline styles

Symbol names (“alist” type):

DEPRECATED (“boolean” type):

Possible values, which can be specified for each heading level (examples further below):

  1. nil (default fallback option—covers all heading levels)
  2. t (default style for a single heading, when the fallback differs)
  3. no-bold
  4. line
  5. line-no-bold
  6. rainbow
  7. rainbow-line
  8. rainbow-line-no-bold
  9. highlight
  10. highlight-no-bold
  11. rainbow-highlight
  12. rainbow-highlight-no-bold
  13. section
  14. section-no-bold
  15. rainbow-section
  16. rainbow-section-no-bold

This supersedes and greatly expands upon what the deprecated variables once offered. It is now possible to (i) benefit from more stylistic choices, and (ii) apply them on a per-level basis.

As always, the defaults remain in tact: headings are just rendered in a bold weight and their colours are not too saturated to offer a plain text impression that relies on typography to convey its meaning.

The info manual explains the details. A few examples:

;; Per-level styles (t means everything else)
(setq modus-operandi-theme-headings
      '((1 . highlight)
        (2 . line)
        (t . rainbow-line-no-bold)))

;; Uniform style for all levels
(setq modus-operandi-theme-headings
      '((t . rainbow-line-no-bold)))

;; Default style for level 1, while others differ
(setq modus-operandi-theme-headings
      '((1 . t)
        (2 . line)
        (t . rainbow-line-no-bold)))

Thanks to Adam Spiers for the feedback in issue 81: https://gitlab.com/protesilaos/modus-themes/-/issues/81. Also thanks to Nicolas De Jaeghere for helping refine relevant stylistic choices: https://gitlab.com/protesilaos/modus-themes/-/issues/90.

No link underlines

Symbol names (“boolean” type):

Possible values:

  1. nil (default)
  2. t

By default, the themes apply an underline effect to links, symbolic links, and buttons. Users can now disable this style by setting the new option to t.

Thanks to Utkarsh Singh for the feedback in issue 94: https://gitlab.com/protesilaos/modus-themes/-/issues/94

No mixed fonts

Symbol names (“boolean” type):

Possible values:

  1. nil (default)
  2. t

By default, the themes configure some spacing-sensitive faces, such as Org tables and code blocks, to always inherit from the fixed-pitch face (documented in the manual). This is to ensure that those constructs remain monospaced when users opt for something like the built-in M-x variable-pitch-mode. Otherwise the layout would break.

The obvious downside with this theme design is that users need to explicitly configure the font family of fixed-pitch in order to apply their desired typeface (how to do this is also covered in the manual). That may be something they do not want to do. Hence this option to disable any kind of font mixing done by the active theme. Set it to t.

Support for new faces or face groups

Thanks to:

Refinements to existing faces

Contributions to the wider community

Sometimes the themes reveal bugs in other packages. It is of paramount importance that we report those to the upstream developers, try to help them reproduce the issue, and, where possible, support them in tracing the problem’s root cause.

Four such cases during this release:

  1. Adaptive Org headings. Solved upstream and documented on my website: https://protesilaos.com/codelog/2020-09-24-org-headings-adapt/. Reported and discussed on the themes’ issue tracker: https://gitlab.com/protesilaos/modus-themes/-/issues/37.

  2. Alignment of Org tags with proportional fonts. Ongoing thread: https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/msg00415.html. Reported and discussed on the themes’ issue tracker: https://gitlab.com/protesilaos/modus-themes/-/issues/85.

  3. Org priority cookie has extra space. Ongoing thread: https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/msg00696.html. Reported and discussed on the themes’ issue tracker, with feedback from Roman Rudakov: https://gitlab.com/protesilaos/modus-themes/-/issues/95.

  4. Company overlay pop-up misaligns items. Reported upstream and acknowledged as a known issue that occurs in certain cases: https://github.com/company-mode/company-mode/issues/1010. Discussion on the themes’ issue tracker, with feedback from Iris Garcia: https://gitlab.com/protesilaos/modus-themes/-/issues/96.

Miscellaneous

This has been yet another period of intense work: reviewing faces and applying colours is never easy, adding new customisation options is always tricky, and documenting everything takes a lot of time (unless you do all of those on a whimsy, which hopefully is not the case here).

Thanks again to everyone who helped improve the themes!