Screen shots of the Modus themes for Emacs
Demonstrating a wide range of options and interfaces
Refer to the Info manual for the specifics of the Modus Operandi and Modus Vivendi themes. In short: they are designed to conform with the highest accessibility standard for relative colour luminance, they are highly customisable, and cover practically every package or interface you may want to use in your Emacs session.
The following correspond to version
0.13.0 and were taken on
2020-09-27. The typeface is my modified version of
Hack, set at point
Click to enlarge the image, because the smaller size can affect your perception of what is on display.
This is what you get out-of-the-box. We try to offer a generic experience that conforms with the overarching accessibility objective of the themes, but is otherwise fairly minimalist.
Mode line variations
You noticed the style of the modelines in the previous screen shots.
Here we showcase the optional three-dimensional effect for the active
modeline or the one that suits the
moody package (as always, check the
3D active modeline
Several customisation options are available for you to tweak the themes to your liking.
Fringe visibility, bold constructs, slanted constructs
By default, the themes will apply a bold weight and a slant (italics font style) only where it is absolutely necessary. They will also not show the space occupied by the fringes. Though you can always change that.
Line numbers, current line, delimiter matching
These show the differences between the default and optional styles for
the current line (
hl-line-mode) and matching delimiters
show-paren-mode). The line numbers are just a common feature that we
include in this demo, because why not?
“Faint” code syntax
Users can opt for a more desaturated style for code syntax highlighting. Here we show it together with the optional “intense” style for fringes (do check the manual, please).
Styles for prose (Org, Markdown…)
In this section we will be covering a lot of
org-mode, but you can
expect the same styles to apply in
markdown-mode and a few others,
when that is possible or makes sense.
Org default style
Org buffers contain a lot of information. We try to avoid applying too intense colouration, though you can always change that.
Org source blocks
Source blocks can be configured to use a standard grayscale style for their background (there is also an option to add an accented background to blocks depending on the programming language they use—ideal for those of you who combine multiple code snippets in your documents).
Here we just show the greyscale style.
Scalable and variable-pitch headings
Setting the options for “scalable” and “variable-pitch” headings can quickly change the tone of your document (check the manual, because the themes also support more advanced “mixed font” configurations).
Granular control over headline styles
The manual explains in detail how to configure things for each heading level, or for all of them at once. There are lots of styles on offer. Here we just demonstrate a few of them.
Headings with “rainbow” style
Apply more saturated colours to all heading levels. This is just for demo purposes, as you can always decide the style of each level individually.
Headings with “section” style
An overline and a tinted background for all heading levels, while retaining the default text colour for each of them (though that too can be changed—consult the manual).
Headings with a variety of styles
Spot the differences between the heading levels on display. Did I tell you that the manual is your friend?
Styles for completion frameworks
A good part of your time with Emacs involves interacting with a
completion framework like the built-in
icomplete (my choice),
The manual explains how to tweak their aesthetics and what kind of grouping is applied to them. The two representatives of each group are Icomplete and Ivy.
Here we use
icomplete in tandem with
orderless. The screenshots cover the default, moderate, opinionated
aesthetics in this order.
Ivy default, moderate, opinionated
As with above, the screenshots encompass the default, moderate, and opinionated aesthetics in this exact order.
By default, all diffs use prominent colour-coded combinations of background and foreground values. Word-wise, or “refined”, diffs are configured accordingly to always convey their information in an unambiguous way. Users can opt for “desaturated” or “foreground only” diff styles, though word-wise changes will always have some background (it changes to match the overall style, but is never removed altogether).
Here we show
magit, but expect more-or-less the same from
smerge-mode, and the like. The images are in order:
And here we just add an
ediff set of examples, because of some extra
styles this mode uses, relative to the other libraries.
Command prompt styles
Here we compare the default, subtle, and intense prompts in this order.
Attention to every detail
We do not merely optimise for the numerous customisation options. We rather make sure that everything else works well. The themes have a wide palette of colours, many of which are dedicated to particular tasks (because technicalities are always in the details that the untrained eye, i.e. armchair designer, blithely ignores).
Dired and diredfl
The various “marks” that you can use in modes like
dired have styles
that convey their function. We also showcase
diredfl as a case where
we do apply a variety of colours while actively avoiding exaggerations
and “rainbow effects”.
Emacs’ fringes can only display bitmap images, which means that assigning just a foreground colour to them is a bad idea for accessibility. We thus opt for a background+foreground combination. It is easy to identify the individual indicators, while none of them is too intense to distract you from whatever it is you are focused on. Also, note the colour-coded underlines (remember that the “red” of the underline is not the same as the one of the fringe or that used elsewhere, due to the peculiar requirements of each element).
Searches, matches, highlights, tooltips
All indicators have a unique purpose. Our task is to convey that in the
final design. Consider how
grep and related functions use a style
that differs from the current and other
isearch matches, and how they
both differ from the item pointed by the mouse as well as from the
All mail readers supported by the themes are carefully designed. Here we just offer a hint at what Gnus’ summary and article buffers look like.
We do cover a lot of workflows. Here is the standard Org agenda.
The point of including a niche tool like
bongo (which I have extended
quite a bit—see my dotemacs), is
to press on with the claim that we do pay close attention to detail.