emacs/protesilaos.modus-themes
1
0
Fork 0
mirror of https://github.com/protesilaos/modus-themes.git synced 2026-09-10 07:16:30 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity
protesilaos.modus-themes/CHANGELOG.org
JD Smith e8dee25bd6 Rewrite modus-themes-with-color to use cl-symbol-macrolet 
To address bugs associated with real color vs. mapped color ordering
and other issues, we swap the let* form construction for
cl-symbol-macrolet.
2026-01-04 09:37:20 -05:00

10988 lines
450 KiB
Org Mode
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

#+TITLE: Change log of the Modus Themes for GNU Emacs
#+AUTHOR: Protesilaos Stavrou
#+EMAIL: info@protesilaos.com
#+OPTIONS: ':nil toc:nil num:nil author:nil email:nil
This document contains the release notes that are included in each
tagged commit on the project's main git repository:
<https://github.com/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>
* DEVELOPMENT
** ~modus-themes-with-colors~ improved again
The recently introduced ~let~-based method exhibits a subtle bug: since
it sorts real colors prior to "mapped" colors, an override from the
latter to the former would be lost.
* 5.2.0 on 2025-12-31
This version fixes some bugs, adds a new feature for those who want to
derive a theme from Modus, and makes other small quality-of-life
refinements.
** The ~modus-themes-with-colors~ should work at all times
In the transition to version =5.0.0=, I inadvertently introduced
regressions to the behaviour of the ~modus-themes-with-colors~ macro.
This macro ~let~ binds the current theme's palette around arbitrary
Elisp expressions, which allows users to access the named colours
therein. In versions =5.0.0= and =5.1.0= the macro could not read
variables defined outside its scope. Users needed to write an ~eval~
around it, which I did not like. Now the macro should not require such
workarounds: it basically is a ~let~ that should work as expected
everywhere.
This was fixed over a series of Git commits related to issue 170:
<https://github.com/protesilaos/modus-themes/issues/170>. Thanks to
Alexandr Semenov and realazy for reporting the problems and testing my
revisions.
** The ~modus-themes-generate-palette~ function to quickly get a palette
Users or package developers who want to create a theme on top of Modus
can now get a kickstart by defining their palette with the help of the
new ~modus-themes-generate-palette~ function. This function is meant
to return a complete palette, given a list of basic colours. Users can
thus experiment with their new theme while knowing that what they got
contains all the definitions; definitions that they may then modify
further (e.g. to define different semantic mappings than the defaults
such as, for example, to have =(fg-heading-1 red-warmer)= instead of
what originally is =(fg-heading-1 fg-main)=).
I have written extensive documentation in the manual, which includes a
complete example of a Solarized theme that is built on top of Modus.
If you have any questions, you are welcome to contact me.
** Convenience commands to select only dark or light themes
The commands ~modus-themes-select-dark~ and ~modus-themes-select-light~
use minibuffer completion to load a theme. The completion candidates
are filtered to only dark or light themes, respectively.
This is effectively the same as calling the command ~modus-themes-select~
with a prefix argument (=C-u= by default).
Remember that we also have the commands ~modus-themes-load-random~,
~modus-themes-load-random-dark~, and ~modus-themes-load-random-light~.
Otherwise use the command ~modus-themes-rotate~.
** Improved prompt for theme selection
The minibuffer prompt used by the various Modus commands to select a
theme now has a grouping function in place: it shows the current theme
at the top and then all other themes grouped by their dark or light
background. This makes it easier to find a relevant theme, especially
if lots of them are present, such as when ~modus-themes-include-derivatives-mode~
is enabled and relevant packages/themes are available (e.g. my
~ef-themes~ and ~standard-themes~).
** Semantic colours for =transient.el= (e.g. in Magit)
The =transient.el= concept of "semantic colours" is now supported.
This is used by default in Magit to denote the different types of
keys, such as those that exit the transient, keep it active, move to
another transient, and the like. Users who prefer the old style where
all key bindings looked the same must customise the user option
~transient-semantic-coloring~.
Note that the deuteranopia- and tritanopia- optimised themes adapt
gracefully to such "semantics", owning to relevant internal
refinements I made. Those themes cannot rely on the full colour
spectrum to communicate such nuances.
** All ~hl-todo-mode~ faces use a bold weight if appropriate
When the user option ~modus-themes-bold-constructs~ is set to a
non-~nil~ value, then all keywords that ~hl-todo-mode~ highlights will
be rendered in a bold weight (technically, they inherit the ~bold~
face). This is how we were doing it before until I undid it by
mistake. Thanks to Dominik Schrempf for reporting the bug in issue
177: <https://github.com/protesilaos/modus-themes/issues/177>.
** Theme-sensitive colours for Gnus mail groups
The Gnus mail groups no longer have hardcoded colour values. They will
look different depending on the current Modus theme.
** Faces that set a =:box= attribute handle unspecified colours
I updated all faces that use a =:box= attribute to account for the
scenario of a user writing palette overrides that unset the relevant
colour. Thanks to JD Smith for reporting a bug along those lines in
issue 9 of my ~standard-themes~ repository (they are derived from the
~modus-themes~, hence the changes here):
<https://github.com/protesilaos/standard-themes/issues/9>.
** The ~calendar-today~ and ~org-date-selected~ faces are disambiguated
These two faces are no longer using the same styles. This is because
they can appear in the same buffer. Thanks to Rudolf Adamkovič for
discussing this with me in the context of the same change for my
~doric-themes~ (issue 20 in doric-themes.git):
<https://github.com/protesilaos/doric-themes/issues/20>.
** The Modus "current theme" respects multiple enabled themes
The Modus concept of "current theme" respects the user's choice for
multiple themes loaded at once. It will return the first Modus theme
even if it is not at the front of the list.
[ Emacs will load multiple themes by default, which leads to awkward
colour combinations, unless you know what you are doing---as such all
the Modus commands that load a theme will disable all others, subject
to the user option ~modus-themes-disable-other-themes~. ]
Thanks to Pierre Téchoueyres for reporting the scenario where multiple
other themes are loaded on top of a Modus theme. This was done in
issue 182: <https://github.com/protesilaos/modus-themes/issues/182>.
Also thanks to Pierre for covering another snippet that I had missed.
This was done in pull request 184:
<https://github.com/protesilaos/modus-themes/pull/184>.
Pierre has assigned copyright to the Free Software Foundation.
** Fixed symbol of inherited AUCTeX face
There was a typo which caused an error. Thanks to Rudolf Adamkovič for
the patch and also for providing a relevant unit test. This was done
in pull request 188: <https://github.com/protesilaos/modus-themes/pull/188>.
Rudolf has assigned copyright to the Free Software Foundation.
** Miscellaneous
- Thanks to Basil L. Contovounesios for simplifying a couple of
expressions. This was done in pull request 190:
<https://github.com/protesilaos/modus-themes/pull/190>. Basil has
assigned copyright to the Free Software Foundation.
- The faces of the built-in ~completion-preview-mode~ are now
supported. Thanks to Kevin Fleming for asking me about this in issue
178: <https://github.com/protesilaos/modus-themes/issues/178>.
- Several faces that had a strike-through effect when they did not
really need it are revised to use a wavy underline instead. The idea
is to let the text be readable at all times, regardless of the
effective font family. With the strike-through effect, some fonts
completely obscure the underlying text.Thanks to Morgan Willcock for
discussing with me the use of the strike-through style in issue 169:
<https://github.com/protesilaos/modus-themes/issues/169>.
- All ~symbol-overlay~ faces are unique, fixing a mistake I had done
before.
- The ~org-dispatcher-highlight~, which is used to highlight the keys
of the Org export interface, now uses the appropriate foreground
colour and is always rendered in a bold weight.
- The ~org-habit~ faces no longer call the function
~readable-foreground-color~. This is because that function does not
work if the theme is loaded via the =early-init.el=. Thanks to
Gaston Cabotin for reporting the problem in issue 174:
<https://github.com/protesilaos/modus-themes/issues/174>.
- The ~gnus-button~, which Gnus uses in all sorts of places to mark
some text as clickable, is styled with a less intense underline and
will no longer follow the style of links, including possible palette
overrides. This way, Gnus article buffers will not have visual
noise. Thanks to Morgan Willcock for discussing this with me in
issue 140: <https://github.com/protesilaos/modus-themes/issues/140>.
* 5.1.0 on 2025-11-07
:PROPERTIES:
:CUSTOM_ID: h:86a4b45a-14e0-45f1-9625-969ad966b9ff
:END:
This version fixes a critical bug in the ~modus-themes-with-colors~
macro. In short, it was not working as before or was not working at
all. Now it should do the right thing.
Thanks to Alexandr Semenov for reporting a relevant bug in issue 170
and for helping me test the results: <https://github.com/protesilaos/modus-themes/issues/170>.
Thanks to Stéphane Marks for testing some configurations with the
latest stable Emacs version as well as with builds from emacs.git.
This was done via a private channel and I am sharing this information
with permission.
Also thanks to Stefan Monnier for monitoring my commits as I was
trying to refactor the ~modus-themes-with-colors~ macro. Some comments
were posted on the emacs-devel mailing list, as well as a patch that I
ended up applying and then reverting (check the commit log for the
technicalities): <https://lists.gnu.org/archive/html/emacs-devel/2025-11/msg00114.html>.
Apologies to everyone for the inconvenience! This was a tricky bug.
The good thing is that it compelled me to improve several parts of the
code.
This version also includes a clarification in the manual about
building a theme on top of Modus:
- Web page :: Visit <https://protesilaos.com/emacs/modus-themes#h:86eb375b-9be4-43ce-879a-0686a524a63b>.
- Info manual :: Evaluate ~(info "(modus-themes) Build on top of the Modus themes")~.
In short, it mentions that a theme exists in an appropriately named
file that is part of the ~custom-theme-load-path~. Thanks to Ashton
Wiersdorf for asking a related question in issue 171:
<https://github.com/protesilaos/modus-themes/issues/171>.
* 5.0.0 on 2025-11-01
:PROPERTIES:
:CUSTOM_ID: h:9232615a-02d7-4376-90a6-7e7570ac1c1e
:END:
This is a major release. There are some small breaking changes. The
big new feature is that Modus can be used as the basis for other theme
projects. Two of my other theme packages, the ~ef-themes~ and the
~standard-themes~ are already done in this way: their next major
versions will formalise what I have been developing for a while now
(though the ~doric-themes~ will remain their own thing for the time
being).
** Build on top of Modus
:PROPERTIES:
:CUSTOM_ID: h:269cd2f9-604d-4e9b-87c8-d9d91fb6d355
:END:
This is of immediate interest to package developers or advanced users.
It changes nothing for existing users of the Modus themes. Please
refer to the manual on the matter and feel welcome to contact me if
you have any questions---I am happy to help.
Evaluate:
#+begin_src emacs-lisp
(info "(modus-themes) Build on top of the Modus themes")
#+end_src
Or visit: <https://protesilaos.com/emacs/modus-themes#h:86eb375b-9be4-43ce-879a-0686a524a63b>.
Why build on top of Modus? To benefit from (i) the wide face coverage
and extensive detail-oriented testing, (ii) the use of palette
mappings, (iii) the palette preview done with
~modus-themes-list-colors~ or related, (iv) the inclusion of the
derivative theme in the workings of all Modus commands that load a
theme, like ~modus-themes-rotate~ and ~modus-themes-select~ (see the
new minor mode ~modus-themes-include-derivatives-mode~).
Derivative themes can be as simple as a few extra colours on top of,
say, ~modus-operandi~. They can also be more involved, with new
palette mappings and custom faces that use them. Such themes can
define commands which load only their own themes (see
~modus-themes-define-derivative-command~) and they can even take over
the Modus themes completely, in terms of becoming the only ones that
are exposed to the commands that load a theme, like
~modus-themes-rotate~ and ~modus-themes-select~.
Thanks to Suleyman Boyar for fixing an intermediate omission with an
earlier version of the code that derives a theme. I did eventually
change the whole approach to use a function instead of a macro, but
Suleyman's contribution was still useful at the time. This was done in
pull request 156: <https://github.com/protesilaos/modus-themes/pull/156>.
The change is small, meaning that Suleyman does not need to assign
copyright to the Free Software Foundation.
** Colours can be copied from the palette preview buffer
:PROPERTIES:
:CUSTOM_ID: h:27ae691a-50bc-4339-af36-7e09e6060f8e
:END:
The commands ~modus-themes-list-colors~ and ~modus-themes-list-colors-current~
display the given theme's palette in a tabulated listing. Each line
visualises the colour it references. From that buffer it is now
possible to call the following commands (bound to the ~modus-themes-preview-mode-map~):
| Default key binding | Name of the command |
|---------------------+----------------------------------------|
| =w= | ~modus-themes-preview-mode-copy-color~ |
| =W= | ~modus-themes-preview-mode-copy-entry~ |
| =m= | ~modus-themes-preview-mode-mark~ |
| =M= | ~modus-themes-preview-mode-mark-all~ |
| =u= | ~modus-themes-preview-mode-unmark~ |
| =U= | ~modus-themes-preview-mode-unmark-all~ |
The ~modus-themes-preview-mode-copy-color~ and its
~modus-themes-preview-mode-copy-entry~ counterpart work on the line at
point or those that are marked. The first copies the resolved colour
value, as a string ("resolved" here means that it will find what a
palette mapping actually stands for). The second gets the complete
palette entry, as it appears in the underlying definition. This is a
starting point for writing palette overrides.
Thanks to shimeike for reporting a problem with a regression I
introduced by mistake in one of the development versions of the
function that handles the creation of the tabulated list. This was
done in issue 163: <https://github.com/protesilaos/modus-themes/issues/163>.
** New semantic palette mappings for programming contexts
:PROPERTIES:
:CUSTOM_ID: h:66f43975-2e97-41e6-85ec-c29e0505bd80
:END:
The ~fnname-call~ and ~variable-use~ are now available. They are
applied to faces that are used by major modes which build on top of
~tree-sitter~ program as well as the Emacs Lisp semantic highlighting
feature of Emacs 31.
By default, these colours are more subtle than their ~fnname~ and
~variable~ counterparts. The reason is that I want to avoid
exaggerations with the wanton application of colour ("avoiding
exaggerations" is one of the design principles of the Modus themes).
Because of the commitment to the highest legibility standard for
colour contrast, we are using colours that stand out in their context,
yet are still harmonious with each other. This is due to (i) careful
consideration of colour harmonies, (ii) enforced uniformity of styles
where necessary to avoid emphasising the emphasis or stating the
obvious, and (ii) the fact that not too many intense colours appear in
close proximity to each other in most Emacs major modes. If a major
mode or other feature adds colours virtually everywhere, then the
Modus themes are no longer true to their character and become
borderline unusable.
The more subtle colours for ~fnname-call~ and ~variable-use~ do not
prevent exaggerations, though they do make them less egregious.
[ Note that themes do not control which face is applied where. That is
the job of a major mode or specialised minor modes. When in doubt,
work with the rule that fewer colours are better than many. ]
** Support for Emacs Lisp semantic highlighting
:PROPERTIES:
:CUSTOM_ID: h:a14057b4-f7e9-4ff7-b40c-7640559f04dc
:END:
This is built into Emacs version 31. What it does is make different
parts of the Elisp syntax stand out visually. It also augments them
with a mouse tooltip (technically a =help-echo=) that provides
valuable insights about what the thing is.
Thanks to Eshel Yaron, the author of this feature, for (i) asking me
to review the relevant faces, (ii) helping me understand what
"semantic highlighting" is intended for, and (iii) explaining to me
how some faces are meant to be used. This was done in the context of
Emacs bug 79677 and in an aside about a change to my minimalist
~doric-themes~ package:
- <https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-10/msg01156.html>.
- <https://lists.gnu.org/archive/html/emacs-devel/2025-10/msg00728.html>.
I wrote to Eshel that I do not want many colours clustered together.
This design is more suitable to themes with low intensity. All my
themes exacerbate the effect of dense colouration due to their primary
design goal: legibility.
Currently the added colouration of semantic highlighting is noticeable
far more than I like. This is a compromise on my end. Future versions
of the themes might set more semantic faces to ~nil~ (or anyhow make
them subtle), subject to further review and user feedback.
This is not a position against semantic highlighting, but a comment on
inconsiderate themes.
** More elements are optionally bold or italic
:PROPERTIES:
:CUSTOM_ID: h:d351403d-97d7-4c7d-b431-f9153201fc1c
:END:
I have revised all supported faces to make them more conservative
about when they apply typographic qualities that deviate from the
default font. Many faces that were unconditionally rendered with a
bold weight or an italic slant are now subject to the user options
~modus-themes-bold-constructs~ and ~modus-themes-italic-constructs~.
This means that they are like the default font family by default and
will become bold/italic if the relevant user option is set to a
non-~nil~ value.
Faces that are semantically bold or italic and/or which genuinely
benefit from such typographic attributes out-of-the-box are exempt
from this.
Headings are also exempt because they are anyway subject to the user
option ~modus-themes-headings~ which covers the height and weight of
each heading level's text.
Thanks to chainedghost for reporting a regression in one of the
commits I made. This was done in issue 167:
<https://github.com/protesilaos/modus-themes/issues/167>
** Support for ~lsp-mode~ and ~lsp-ui~ packages
:PROPERTIES:
:CUSTOM_ID: h:4e9b6d96-d760-40b9-b293-609bf76ba569
:END:
Thanks to Jimmy Yuen Ho Wong for the initial contribution in pull
request 142: <https://github.com/protesilaos/modus-themes/pull/142>.
I made some changes on top to use semantic palette mappings, where
applicable, and other such tweaks.
** The ~minibuffer-nonselected~ face is supported
:PROPERTIES:
:CUSTOM_ID: h:8f2422e7-66cc-42d4-8d9f-8a4ad255b3eb
:END:
This is coming in Emacs version 31: it highlights the active
minibuffer when the cursor is in another window. The face is designed
to be as noticeable as possible because this kind of scenario usually
leads to mistakes or confusion.
** Refinements to supported packages or face groups
:PROPERTIES:
:CUSTOM_ID: h:81607d59-176a-4fad-aacd-0f946e228682
:END:
- The ~markdown-code-face~ uses the same semantic palette mapping as
~org-block~. This was always the intent. Thanks to Frédéric Giquel
for the fix in pull request 160: <https://github.com/protesilaos/modus-themes/pull/160>.
The change is small and thus does not require copyright assignment
to the Free Software Foundation.
- Fixed a word in the symbol of the ~flymake-warning-echo-at-eol~. Thanks to
Eric Ottosson for the patch in pull request 145: <https://github.com/protesilaos/modus-themes/pull/145>.
No copyright assignment is required.
- The two new Emacs 31 faces for packages that are marked for
installation or deletion in the =M-x list-packages= buffer are now
included. Thanks to Gautier Ponsinet for sending me the patch.
Gautier has assigned copyright to the Free Software Foundation.
- The ~hs-ellipsis~ in Emacs 31 from the built-in ~hideshow~ package
is also covered. It is made to conform with established patterns
across conceptually equivalent faces (e.g. Org folded headings)
rather than do its own thing.
- The ~widget-field~ uses an underline to be easier to spot. On
supported Emacs displays (generally graphical Emacs) the underline
is at the descent line, meaning that it does not cross through
characters with descenders like =g=.
- The ~git-commit~ and ~log-edit~ faces for writing commit messages in
Magit and VC are tweaked to avoid exaggerations.
- The Magit section headings have a slightly modified foreground
value.
- The ~org-list-dt~ face for list definition terms has a slightly
modified foreground value to (i) be easier to spot while (ii) being
less intense overall.
- The ~calendar-today~ in the =M-x calendar= interface now has a box
around it on supported displays (graphical Emacs) to better stand
out from its context. On unsupported displays, the face still gets
an appropriate background value.
- The ~org-date-selected~ and ~calendar-today~ should look the same,
contrary to how they did before. This is done in the interest of
theme-wide consistency (i.e. the kind of detail you appreciate once
it is no longer there).
- The mode lines use an underline on displays that cannot render a
box. This way, the faces remain distinct from their context.
- All interface buttons, like those that appear in the Custom buffers,
will be rendered with an underline on displays that cannot handle
boxes.
- The ~notmuch-message-summary-face~, which is used in threaded
message views, now has an overline on supported displays (graphical
Emacs). Individual messages in the thread should thus be more
discernible.
- The ~tab-bar-tab-highlight~ is directly covered to make sure all
mouse hover effects are consistent across similar interfaces.
- Some faces that had specific colour values (e.g. ~cyan-cooler~) are
revised to use semantic palette mappings instead. This ensures
thematic consistency. The most obvious beneficiaries are users of
the deuteranopia- and tritanopia- optimised themes
(deuteranopia-friendly themes cannot work with red and green while
tritanopia-friendly themes must not rely on yellow and blue).
** The ~modus-themes-custom-auto-reload~ is obsolete
:PROPERTIES:
:CUSTOM_ID: h:a82d2ccb-dd26-410e-8fc8-6f45813b4e00
:END:
Plus all our user options no longer specify a =:set= function. This
means that the theme will never be reloaded automatically when using
the Custom interface or ~setopt~ to configure one of the theme's user
options. Reloading the theme is what applies the new styles. The idea
of this feature is good, but the implementation was problematic. Maybe
I will reinstate it in the future, though I cannot let it block this
major release.
** Several =modus-themes-*= faces are obsolete
:PROPERTIES:
:CUSTOM_ID: h:d5de3be7-5fdc-407b-81fc-aeb99ad528f7
:END:
In previous versions I was defining faces that were used to apply
uniform styles across many packages. This was the old way of doing
things before version =4.0.0= of the themes that introduced palettes
with semantic mappings and, optionally, user-defined overrides to
them.
I have deprecated all of the following and made all the necessary
changes (i.e. several thousands of them), to make palette mappings the
norm everywhere. In general, I encourage you not to rely on any faces
defined by Modus: they are really intended for internal use.
- ~modus-themes-fg-blue~
- ~modus-themes-fg-blue-cooler~
- ~modus-themes-fg-blue-faint~
- ~modus-themes-fg-blue-intense~
- ~modus-themes-fg-blue-warmer~
- ~modus-themes-fg-cyan~
- ~modus-themes-fg-cyan-cooler~
- ~modus-themes-fg-cyan-faint~
- ~modus-themes-fg-cyan-intense~
- ~modus-themes-fg-cyan-warmer~
- ~modus-themes-fg-green~
- ~modus-themes-fg-green-cooler~
- ~modus-themes-fg-green-faint~
- ~modus-themes-fg-green-intense~
- ~modus-themes-fg-green-warmer~
- ~modus-themes-fg-magenta~
- ~modus-themes-fg-magenta-cooler~
- ~modus-themes-fg-magenta-faint~
- ~modus-themes-fg-magenta-intense~
- ~modus-themes-fg-magenta-warmer~
- ~modus-themes-fg-red~
- ~modus-themes-fg-red-cooler~
- ~modus-themes-fg-red-faint~
- ~modus-themes-fg-red-intense~
- ~modus-themes-fg-red-warmer~
- ~modus-themes-fg-yellow~
- ~modus-themes-fg-yellow-cooler~
- ~modus-themes-fg-yellow-faint~
- ~modus-themes-fg-yellow-intense~
- ~modus-themes-fg-yellow-warmer~
- ~modus-themes-intense-blue~
- ~modus-themes-intense-cyan~
- ~modus-themes-intense-green~
- ~modus-themes-intense-magenta~
- ~modus-themes-intense-red~
- ~modus-themes-intense-yellow~
- ~modus-themes-key-binding~
- ~modus-themes-lang-error~
- ~modus-themes-lang-note~
- ~modus-themes-lang-warning~
- ~modus-themes-mark-alt~
- ~modus-themes-mark-del~
- ~modus-themes-mark-sel~
- ~modus-themes-nuanced-blue~
- ~modus-themes-nuanced-cyan~
- ~modus-themes-nuanced-green~
- ~modus-themes-nuanced-magenta~
- ~modus-themes-nuanced-red~
- ~modus-themes-nuanced-yellow~
- ~modus-themes-prominent-error~
- ~modus-themes-prominent-note~
- ~modus-themes-prominent-warning~
- ~modus-themes-prose-code~
- ~modus-themes-prose-macro~
- ~modus-themes-prose-verbatim~
- ~modus-themes-search-current~
- ~modus-themes-search-lazy~
- ~modus-themes-search-replace~
- ~modus-themes-search-rx-group-0~
- ~modus-themes-search-rx-group-1~
- ~modus-themes-search-rx-group-2~
- ~modus-themes-search-rx-group-3~
- ~modus-themes-search-static~
- ~modus-themes-subtle-blue~
- ~modus-themes-subtle-cyan~
- ~modus-themes-subtle-green~
- ~modus-themes-subtle-magenta~
- ~modus-themes-subtle-red~
- ~modus-themes-subtle-yellow~
Thanks to Kevin Fleming and Jimmy Yuen Ho Wong for fixing two cases of
unbalanced/faulty parentheses caused by the aforementioned. These were
done as pull requests 166 and 168, respectively:
- <https://github.com/protesilaos/modus-themes/pull/166>.
- <https://github.com/protesilaos/modus-themes/pull/168>.
Both changes are small: no copyright assignment to the Free Software
Foundation is needed (and I think both authors are covered, anyway).
** All =:inherit= face attributes are reviewed and kept to a minimum
:PROPERTIES:
:CUSTOM_ID: h:45ecd8f2-509b-4519-bd62-087031b0c1b8
:END:
The themes now use the =:inherit= attribute much more cautiously than
before. This is because of the reliance on semantic palette mappings:
those give us more control and usually are explicit about the desired
result.
Face inheritance can become circular in some cases. Newer Emacs
versions throw an error accordingly. This was discussed in Emacs bug
79672, with participation from Eli Zaretskii, JD Smith, Manuel Giraud,
Stephane Marks, and Steven Allen: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79672>.
Thanks to everybody involved!
* 4.8.0 on 2025-06-11
:PROPERTIES:
:CUSTOM_ID: h:a8d31a81-5283-494a-bfb0-982206bcb2bd
:END:
This is a small release that corrects a mistake I made in the previous
version. It also introduces some minor refinements.
** Matching parentheses are easy to spot
:PROPERTIES:
:CUSTOM_ID: h:66e472d7-444c-4cbe-b505-b05f586cc9f5
:END:
In version =4.7.0=, I made the mistake of merging some stylistic
tweaks to ~show-paren-mode~ that I was experimenting with. The idea
was to get a feel for how the subtle colouration of matching
delimiters affects the usability of the themes. In short, it is not a
good default for our purposes (though users have the option to
override the applicable colours, as explained in the Modus themes
manual).
Thanks to Morgan Willcock for reporting the unwanted change in issue
139: <https://github.com/protesilaos/modus-themes/issues/139>.
** The =bg-paren-match= of ~modus-vivendi-tinted~ is a bit greener
:PROPERTIES:
:CUSTOM_ID: h:776e2c72-f3ed-4df1-809f-e9e64b68c029
:END:
We go from =#5f789f= to =#4f7f9f=. The latter fits better with the
rest of the theme.
** Refined the "mail" semantic mappings of the tinted themes
:PROPERTIES:
:CUSTOM_ID: h:1caccaff-5e19-4941-8ce0-1612f9017d27
:END:
This concerns =message.el= and anything building on top of it, like
Gnus, Mu4e, and Notmuch. I made ~modus-operandi-tinted~ and
~modus-vivendi-tinted~ use two colours that are more in line with the
established patterns of their respective theme. The changes are small,
but contribute to a more consistent experience.
** A new =property= semantic mapping is available
:PROPERTIES:
:CUSTOM_ID: h:79c0c8b8-a239-4ddf-be91-3a70669f373f
:END:
By default, it uses the same colour as the =variable=. Users who want
to have more refined colouration in supported modes (typically
involving tree-sitter), can change the relevant "palette overrides"
user option we provide, such as ~modus-themes-common-palette-overrides~
or ~modus-operandi-palette-overrides~ and related.
Thanks to Alexandr Semenov for requesting this in issue 141:
<https://github.com/protesilaos/modus-themes/issues/141>.
** My ~tmr~ package is now supported
:PROPERTIES:
:CUSTOM_ID: h:ed447d82-b709-4b69-8f46-15abfc7877f6
:END:
Its faces were already consistent with the Modus themes, though now I
cover them at the theme level to subject them to palette overrides.
** The "ancient" Gnus messages are styled properly
:PROPERTIES:
:CUSTOM_ID: h:2af608e7-409c-413a-b356-a441af704f11
:END:
Those are only ever seen if the user configures Gnus in a certain way
and follows a specific workflow. They now get a subtle foreground
value. This is in response to the issue 119 by sivaramn:
<https://github.com/protesilaos/modus-themes/issues/119>.
** The ~modus-themes-rotate~ command can now go backwards
:PROPERTIES:
:CUSTOM_ID: h:87ed7847-62d5-4fe4-b05c-8e2d1c390528
:END:
When called with a prefix argument (=C-u= by default), this command
will rotate the ~modus-themes-to-rotate~ from right to left.
Otherwise, it goes from left to right.
Thanks to Jacob S. Gordon for the contribution. It was sent as a
patch as part of issue 143:
<https://github.com/protesilaos/modus-themes/issues/143>.
* 4.7.0 on 2025-04-17
:PROPERTIES:
:CUSTOM_ID: h:1ee2b685-2032-45a2-8a23-70e07dafd036
:END:
This release introduces many subtle stylistic tweaks to the "tinted",
"deuteranopia", and "tritanopia" theme variants.
** The ~modus-themes-list-colors~ command uses a tabulated list
:PROPERTIES:
:CUSTOM_ID: h:ed1454aa-537c-44cf-badf-846894e01d42
:END:
This command and its ~modus-themes-list-colors-current~ help users see
the colour values and semantic palette mappings defined by the given
theme. In the past, their buffer was designed in the same spirit as
that of the command ~list-faces-display~, whereas now it is like the
buffer of the command ~list-packages~. Concretely, users may now sort
by column. Do =M-x describe-mode= while in that buffer to learn about
the available commands and their respective key bindings.
** The "tinted" themes have slightly different colours
:PROPERTIES:
:CUSTOM_ID: h:cd8dbafa-3c70-4f2d-8a2c-d9f1db05ec4b
:END:
The overall feel of the ~modus-operandi-tinted~ and ~modus-vivendi-tinted~
themes is the same as before. Though in a side-by-side comparison between the
old and new versions reveals lots of subtle differences. The general
idea is to make the themes a bit more consistent by tweaking the
foreground values to be more harmonious in combination with their
background.
** The "deuteranopia" themes are more consistently blue and yellow
:PROPERTIES:
:CUSTOM_ID: h:03efa3e2-d0d7-4699-9064-00d51dfc8932
:END:
These are the ~modus-operandi-deuteranopia~ and ~modus-vivendi-deuteranopia~,
which are optimised for users with red-green colour deficiency. In the
past, these themes used blue and yellow hues wherever a concept of
"success" versus "failure" had to be established. This approach is
more generalised now, to include programming syntax highlighting and
many other contexts. In short, the themes are more blue+yellow, while
retaining their original feel.
** The "tritanopia" themes are more consistently red and cyan
:PROPERTIES:
:CUSTOM_ID: h:f759ffa1-0750-455f-8dea-5b9bd9b909e3
:END:
As above, the ~modus-operandi-tritanopia~ and ~modus-vivendi-tritanopia~
themes, which are optimised for users with blue-yellow colour deficiency,
use a red+cyan palette in more places. Overall, they feel like they
did before, only they are more consistent.
** Miscellaneous
:PROPERTIES:
:CUSTOM_ID: h:bce8903f-9663-4bee-bcd5-b38ba4e85840
:END:
- Extended support for the ~icomplete~ faces that are coming in Emacs
version 31.
- Added support for ~treemacs~ faces, courtesy of Rahul Juliato in
pull request 121: <https://github.com/protesilaos/modus-themes/pull/121>.
Rahul has assigned copyright to the Free Software Foundation.
- Added support for the ~tldr~ package.
- Extended support for ~adoc-mode~. Thanks to Leilei332 for the
contribution in pull request 137: <https://github.com/protesilaos/modus-themes/pull/137>.
The change is within the ~15-line limit, meaning that the author
does not need to assign copyright to the Free Software Foundation.
- Added support for my ~spacious-padding~ package, specifically the
faces it can use when the ~spacious-padding-subtle-mode-line~ user
option is enabled.
- Added support for the ~howm~ package.
- Extended support to the new faces of the ~transient~ package. More
specifically, all those faces use the same colour for key bindings
because the idea of colour coding keys (e.g. light yellow means
something different than dark blue) does not work in practice when
considering accessibility. Such semantics should not be limited to
differences in colour: they should also have distinct indicators,
such as ASCII or Unicode characters.
- Revised the ~avy~ package's faces to only use one coloured
background. The multiple coloured backgrounds have been a perennial
problem for our accessibility requirements and have made the themes
needlessly more complex just to support an edge case. With this
simplified style, ~avy~ continues to work fine: it simply is less
flamboyant. Other interfaces with ~avy~-like model of interaction,
such as optional extensions to the ~vertico~ and ~corfu~ packages,
have these same changes, in the interest of consistency.
- Update the ~meow~ sample configuration in the manual. This package
is not directly supported at the theme level because (i) I do not
use it and (ii) it is very hard for an outsider to it to trigger the
display of all of its faces in the right context. Without seeing how
all of them look together, I cannot come up with a reliable design.
The manual offers a "good enough" approximation.
- Broadened the support of the ~vterm~ faces to include the "bright"
colours, while updating those that were already covered. Thanks to
Edgar Vincent for informing me that some of the vterm faces were
changed a while ago. This was done in issue 317 on the GitLab
mirror: <https://gitlab.com/protesilaos/modus-themes/-/issues/317>.
- Revised the ~org-column-title~ face to inherit the ~fixed-pitch~
face if the user option ~modus-themes-mixed-fonts~ is non-nil. This
user option makes it possible to have a buffer with proportionately
spaced fonts (such as by enabling ~variable-pitch-mode~), while
keeping spacing-sensitive elements, like tables and code blocks, in a
monospaced font.
Thanks to pedro-nonfree for bringing this matter to my attention in
issue 129: <https://github.com/protesilaos/modus-themes/issues/129>.
- Simplified the helper function ~modus-themes--retrieve-palette-value~
to make it more efficiently. Thanks to Basil L. Contovounesios for
the contribution in merge request 60 on the GitLab mirror:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/60>.
- Reworded the minibuffer prompt of the ~modus-themes-list-colors~
command.
- Made Ivy and IDO subdirectories and "virtual" buffers easier to tell
apart from matching text highlights.
- Included coverage for the ~auto-dim-other-buffers-hide-face~ of the
package ~auto-dim-other-buffers~
- Covered the built-in ~abbrev-table-name~ face.
* 4.6.0 on 2024-10-27
:PROPERTIES:
:CUSTOM_ID: h:6d2d7b60-8233-489b-bb49-bf9cec63ed86
:END:
This is a small release that makes minor refinements to an already
stable base.
** Command to rotate between selected Modus themes
:PROPERTIES:
:CUSTOM_ID: h:8954572d-52ae-4b45-81fa-f9a122d3f643
:END:
The command ~modus-themes-rotate~ switches from one theme to the next
in the list defined in the user option ~modus-themes-to-rotate~. The
default value of the user option covers all the Modus themes, though
users may prefer to set it to a small subset thereof.
Rotation works in such a way that (i) if the theme-to-be-loaded is
already the current one, the next in line is loaded instead, and (ii)
the next candidate is always to the right of the currently loaded
theme.
The rotation is done from left to right. When at the end of the list,
"right" points to the beginning.
The command ~modus-themes-rotate~ complements the existing commands
~modus-themes-toggle~ (which reads the user option ~modus-themes-to-toggle~
to switch between two themes) and ~modus-themes-select~ to select one
among all the Modus themes using minibuffer completion.
** More accurate faces for Org agenda dates
:PROPERTIES:
:CUSTOM_ID: h:fe22ae0c-9577-4aab-9b33-b162b1def6e0
:END:
We now adopt a more semantically consistent approach to the use of
font weights and colour intensity when styling all the permutations of
scheduled date and deadline faces. Pressing tasks stand out more,
while those that do not require immediate attention are rendered in a
more subtle style.
Thanks to Adam Porter (aka GitHub alphapapa) for suggesting this
revision and discussing the technicalities with me. This was done in
issue 102: <https://github.com/protesilaos/modus-themes/issues/102>.
** A slightly revised ~red-cooler~ palette entry
:PROPERTIES:
:CUSTOM_ID: h:e8231f47-070b-4cac-82ec-db839b020291
:END:
The value of this named colour now has a lower contribution from the
blue channel of light, meaning that it looks less pink and more rosy
red. The change is small, though it contributes to a more harmonious
distribution of colour in certain major modes that have preprocessor
constructs (e.g. for the C language).
~red-cooler~ is also used in some contexts in Org and Org agenda
buffers.
** Completion popups are monospaced if ~modus-themes-mixed-fonts~ is non-nil
:PROPERTIES:
:CUSTOM_ID: h:808265fb-6c33-4836-babf-75089bddbe33
:END:
The user option ~modus-themes-mixed-fonts~ ensures that
spacing-sensitive constructs are always rendered in a monospaced font
(technically, they inherit the ~fixed-pitch~ face). This is especially
useful when enabling ~variable-pitch-mode~ in, say, an Org buffer that
has tables and code blocks.
The popup produced by the ~corfu~ and ~company~ packages will also be
rendered in a monospaced font if the necessary conditions are met,
ensuring proper alignment of all the elements.
** Directory icon colours are in line with each theme's palette
:PROPERTIES:
:CUSTOM_ID: h:4aae495b-df39-4032-8b90-ff29f8dfe885
:END:
The directory icon presented by the ~all-the-icons~ and ~nerd-icons~
packages is now rendered in the style of a semantic palette mapping
from the active theme, instead of using a hardcoded faint cyan colour.
This is to ensure that styles are consistent and that users with
deuteranopia or tritanopia get the desired colours while using the
relevant Modus themes.
For those who define palette overrides to refashion the themes, the
mapping is called ~accent-0~: it is used in places where one or more
colours are needed for variation, such as what ~orderless~ does in the
minibuffer or ~magit~ in its status buffer.
** Refined support for ~embark~ and ~forge~ packages
:PROPERTIES:
:CUSTOM_ID: h:ce49c85e-e4a9-4584-9bfb-ce326b16710b
:END:
We now cover more of their faces, have updated the relevant symbols of
those faces, and have made stylistic tweaks in the interest of
theme-wide consistency (i.e. the kind of quality you only appreciate
over time).
** Support for the built-in ~hexl-mode~
:PROPERTIES:
:CUSTOM_ID: h:ec2dfe30-2e37-40b5-8216-31408d46345f
:END:
It was using some background colour values that were somewhat hard to
read. Those are replaced with appropriate foreground colours.
** Documentation on how to support some packages
:PROPERTIES:
:CUSTOM_ID: h:3003e37b-1003-4c37-891a-6715b7ba2fd6
:END:
These are:
- ~combobulate~. Thanks to Damien Cassou in issue 108: <https://github.com/protesilaos/modus-themes/issues/108>.
- ~engrave-faces~.
- ~howm~. Thanks to Jabir Ali Ouassou for the discussion in issue 117: <https://github.com/protesilaos/modus-themes/issues/117>.
- ~meow~. Thanks to ZharMeny in issue 116: <https://github.com/protesilaos/modus-themes/issues/116>.
Those are not covered by the themes for a variety of reasons, but that
may change in the future.
** Updated a colour value about the ~solaire~ package
:PROPERTIES:
:CUSTOM_ID: h:40713198-37a4-4d62-a2c3-4081a02a6641
:END:
This is another package whose support we only document. The manual was
referring to a colour that has long been removed from the themes.
Thanks to Edgar Vincent for bringing this matter to my attention. This
was done on the GitLab mirror, issue 316:
<https://gitlab.com/protesilaos/modus-themes/-/issues/316>.
** Removed some needless =:set= values from ~defcustom~ forms
:PROPERTIES:
:CUSTOM_ID: h:3c46d5c4-93e9-4b1b-be6b-3928bb732099
:END:
We did this after reviewing the state of the code following a
discussion with shipmints and Adam Porter about the behaviour of the
~setopt~ macro when setting user options from the Modus themes. There
should be no visible change for users, though the edit is still useful
for the maintainability of the code. This was done in issue 118:
<https://github.com/protesilaos/modus-themes/issues/118>.
** Switched to ~if-let*~ and its variants everywhere
:PROPERTIES:
:CUSTOM_ID: h:52529f64-1692-419d-91cd-0c37fb10c9a0
:END:
Emacs 31 deprecates the forms of these macros that lack the asterisk.
We can comply right away since the functionality is the same.
* 4.5.0 on 2024-08-21
:PROPERTIES:
:CUSTOM_ID: h:1a3e2de7-2244-4160-a29c-40a0ab35cd5f
:END:
The themes are in a stable state. They cover a wide range of packages
and interfaces, while they are highly configurable. The present
version provides further scope for customisation as well as some
quality-of-life refinements.
** Users can now extend the palette of each/all themes
:PROPERTIES:
:CUSTOM_ID: h:9f38b395-9ab0-4b81-a9cd-3e753e6c62b9
:END:
In addition to palette overrides, users can now define extensions for
the palette of each theme or for all themes. The idea is to define new
colours while keeping the existing ones intact. Then, those colours
can be accessed in all the usual ways via (i) the
~modus-themes-with-colors~ macro, (ii) the function
~modus-themes-get-color-value~, and (iii) in the palette override user
options.
I wrote about this on my website: <https://protesilaos.com/codelog/2024-06-25-emacs-modus-themes-user-palette/>.
And, as always, the manual is the up-to-date reference for everything
you need.
The relevant user options are the following:
- ~modus-themes-common-palette-user~
- ~modus-operandi-palette-user~
- ~modus-operandi-tinted-palette-user~
- ~modus-operandi-deuteranopia-palette-user~
- ~modus-operandi-tritanopia-palette-user~
- ~modus-vivendi-palette-user~
- ~modus-vivendi-tinted-palette-user~
- ~modus-vivendi-deuteranopia-palette-user~
- ~modus-vivendi-tritanopia-palette-user~
** More colours to chose from in customisations
:PROPERTIES:
:CUSTOM_ID: h:7b67da30-eb71-4752-8d09-91052faa9277
:END:
A big part of the themes' customisability is the palette overrides
users can implement. The manual covers lots of examples. The short
version is that the user can change how, say, the mode lines look,
what an Org heading looks like, and so on.
We now have a new pair of background and foreground colours, namely,
~bg-clay~ and ~fg-clay~, as well as foreground values to complement
their already existing background counterparts: ~fg-ochre~,
~fg-lavender~, ~fg-sage~.
** "Graph" colours look a bit better in context
:PROPERTIES:
:CUSTOM_ID: h:f7d7a69c-0125-479f-9b35-8b2ba750fa23
:END:
Each theme's palette contains a subset of colour values that are
intended for use in graphs. One well-known package where those are
applied is the ~org-habit~ consistency block.
I tweak a few colours in this subset to make them look better
side-by-side as well as in other combinations. This concerns all the
light themes.
** The indicator for minibuffer recursion has a different style
:PROPERTIES:
:CUSTOM_ID: h:c5079296-74f2-4fe5-8c40-34b11db5a931
:END:
This concerns the number shown next to the minibuffer prompt while in
a recursive minibuffer (per ~minibuffer-depth-indicate-mode~ and
related settings to enable minibuffer recursion). Before, the style
was like a mouse highlight, which could be confusing in certain
situations. Now it is an unambiguous coloured background that still
stands out nicely.
** The ~kmacro-menu~ faces are also supported
:PROPERTIES:
:CUSTOM_ID: h:b8294884-9c8c-45d7-b372-b2fb7fbdb100
:END:
These are the marks we see while using the interface provided by the
built-in command ~kmacro-menu~ (alias ~list-keyboard-macros~).
** The ~vtable~ will respect the user choice for "mixed fonts"
:PROPERTIES:
:CUSTOM_ID: h:5ea1131d-1529-45bf-a86f-4c3778177455
:END:
The ~vtable~ face will be rendered in a monospaced font (technically,
it will inherit ~fixed-pitch~) if the user sets the user option
~modus-themes-mixed-fonts~ to a non-nil value. Users may want to do
this to eventually apply a proportionately spaced font for regular
prose while keeping spacing-sensitive elements like blocks and tables
in a monospaced view.
[ The manual shows how to configure the individual font families via
their respective faces. ]
Thanks to shipmints for bringing this matter to my attention in issue
110: <https://github.com/protesilaos/modus-themes/issues/110>.
** The ~jabber~ package is now supported
:PROPERTIES:
:CUSTOM_ID: h:725123b9-31ed-460b-9411-c2cd9f54502c
:END:
Thanks to Thanos Apollo for the contribution. The change is within
the accepted line limit, meaning that Thanos does not need to assign
copyright to the Free Software Foundation.
** The ~doom-modeline~ no longer uses ~bold-italic~
:PROPERTIES:
:CUSTOM_ID: h:28e9a11b-54b0-4df6-9b96-b2db54a2e43e
:END:
This style was used to highlight some forms of emphasis, but it turns
out that it can clip the outline of icon fonts (per the ~nerd-fonts~
package) under some situations.
** Covered the built-in ~window-tool-bar-mode~
:PROPERTIES:
:CUSTOM_ID: h:92b3a588-4d0d-4afd-bb79-31884836292f
:END:
Thanks to Jared Finder for the contribution. The change is small,
meaning that Jared does not need to assign copyright to the Free
Software Foundation.
** Miscellaneous
:PROPERTIES:
:CUSTOM_ID: h:e3617c15-1909-48f2-9a7d-3243a45fc07b
:END:
- The ~elisp-shorthand-font-lock-face~ is now easier to spot in
context. This is a way for Emacs packages to define so-called
"shorthands" of short prefixes in symbols that are aliases for
longer ones. These shorthands will now use a style that is not found
anywhere else in Elisp code, making them stand out more.
- Added partial support for the built-in ~viper~ package. NOTE though
that this package is applying colors to cursors in a way that themes
cannot override. The issue is especially problematic when switching
themes. If anyone is using Viper and interested to modernise it, let
me know about your work and then I will update the themes
accordingly. Thanks to ZharMeny for asking me to support Viper in
issue 115: <https://github.com/protesilaos/modus-themes/issues/115>.
- Fixed the symbol of an inherited face in ~web-mode~. Thanks to Pavel
Novichkov for the change. It does not require copyright assignment.
- Updated the manual to cover the aforementioned.
* 4.4.0
:PROPERTIES:
:CUSTOM_ID: h:4025f2f4-8524-49d9-9ee5-627361ff9875
:END:
Before I cover the changes, a brief note about the canonical source of
the ~modus-themes~ source code and corresponding documentation.
The ~modus-themes~ are built into Emacs, as of version 28, but they
are not developed in =emacs.git=: I maintain my own Git repository
(<https://github.com/protesilaos/modus-themes>) and sync with
=emacs.git= whenever I publish a new version, such as this one. This
means that my code is often ahead of the one in the Emacs tree
(including the =master= branch). Similarly, the official manual, which
is hosted on my website (<https://protesilaos.com/emacs/modus-themes>),
covers topics not found in the corresponding =gnu.org= web pages.
In the opening section of the manual I include references to the
canonical sources, but I still get comments about GNU web pages that I
do not control. Please check those links before reporting issues that
I can do nothing about.
** No more SourceHut
:PROPERTIES:
:CUSTOM_ID: h:56191859-93e5-444a-9356-f393343619a5
:END:
Development continues on GitHub with GitLab as a mirror. I explained
my reasons here: <https://protesilaos.com/codelog/2024-01-27-sourcehut-no-more/>.
This is a change that affects all my Emacs packages.
** Code blocks now have a background by default
:PROPERTIES:
:CUSTOM_ID: h:6b40d5f3-ae0a-4ec5-ab23-20ec64e37773
:END:
The user option ~modus-themes-org-blocks~ is obsolete. All code blocks
now have a subtle grey background out-of-the-box. The block delimiter
lines, such as the =#+begin_src= in Org mode, use the same background
as the block's contents. This produces a style that (i) is easy to
notice and (ii) employs minimal colouration. Furthermore, we no longer
have any discrepancy between Org and similar modes like Markdown.
Every theme has relevant semantic palette mappings to affect the
underlying faces:
- =bg-prose-block-delimiter=
- =fg-prose-block-delimiter=
- =bg-prose-block-contents=
The old =prose-block= is now renamed to =fg-prose-block-delimiter=.
Please update any such references in your configuration file.
Users can customise those either for all themes via the user option
~modus-themes-common-palette-overrides~ or on a per-theme basis with
something like ~modus-operandi-palette-overrides~. The manual includes
ready-to-use code samples that showcases the numerous permutations made
possible by these new mappings: <https://protesilaos.com/emacs/modus-themes#h:f44cc6e3-b0f1-4a5e-8a90-9e48fa557b50>.
The old option to affect the user option ~org-src-block-faces~ as to
have a different background for each specified programming language is
no longer available. The previous design was inflexible, as I was
hardcoding values for a few languages. Whereas it is better to empower
the user with the choice of =language->colour= association. The manual
shows how to do this:
<https://protesilaos.com/emacs/modus-themes#h:8c842804-43b7-4287-b4e9-8c07d04d1f89>.
** More semantic mappings more inline code in prose-centric modes
:PROPERTIES:
:CUSTOM_ID: h:1d6ae039-cc19-479f-b16f-839481f3080a
:END:
For Org, Markdown, and related we have semantic palette mappings that
target inline code constructs. For example, in Org we can have text
inside of tilde signs to mark it up as code. In prior versions, the
mappings were limited to just a foreground, but now they cover
background values as well. By default, these background do not have a
colour associated with them, meaning that the out-of-the-box aesthetic
is the same as before. Users simply have more power at their disposal
to tweak the theme to their liking.
Here are the names of those mappings:
- =bg-prose-code=
- =fg-prose-code=
- =bg-prose-macro=
- =fg-prose-macro=
- =bg-prose-verbatim=
- =fg-prose-verbatim=
The old =prose-code=, =prose-macro=, and =prose-verbatim= are named
=fg-prose-code=, =fg-prose-macro=, =fg-prose-verbatim=. Please
update any such references in your configuration file.
The manual shows lots of examples on how to benefit from these
optional backgrounds: <https://protesilaos.com/emacs/modus-themes#h:bb5b396f-5532-4d52-ab13-149ca24854f1>.
** No colour-coding for =transient.el= buffers.
:PROPERTIES:
:CUSTOM_ID: h:0b134a92-9554-4578-a963-ef782f224b28
:END:
In a recent version of =transient.el=, there is a new user option that
applies colour-coding to keys (e.g. we see those while using ~magit~):
~transient-semantic-coloring~. This option is enabled by default,
changing the previous style that was used as a reference for all my
designs.
The idea with such colour coding is to indicate when a key continues
to display the transient, exits with a given action, and the like. For
our purposes this interface cannot work:
- We need some place to teach users what each colour means, as there
are no indicators of any sort to help them (whereas, say, in diff
buffers we have the plus and minus signs).
- Not all hues are suitable for highlighting a single character. In
light themes, for example, green and yellow colours are awkward
choices for the requirements of this interface where the key must be
clearly visible. But when we introduce multiple colours, each with
their own meaning, we will not be able to avoid those hues.
- The style of key bindings is not limited to =transient.el=. We find
them when we invoke =M-x=, do =M-x describe-bindings=, while using
the ~which-key~ package, and many more. If we are to change how =transient.el= shows key bindings, then we have to retain the same
visual cues for other contexts. Otherwise, everything is inconsistent.
- All themes must use the same colours to preserve the colour coding,
thus removing an important aspect of their presentation.
- This whole paradigm does not work for themes that are optimised for
users with colour deficiency, due to the reduced number of suitable
hues. With deuteranopia, for example, we can only rely on yellow and
blue: since yellow is not optimal for single key highlights against
a light backdrop, blue is the only hue that works in such a context.
The ~modus-themes~ will never support ~transient-semantic-coloring~.
All relevant faces use the style of standard key bindings.
Themes can enforce user option values, but I have decided to change
the faces instead to better communicate my intent. If a user wants
semantic colouring, they can change the faces to whatever they like.
I understand this is a radical measure, though it is the best I can do
given the circumstances. If =transient.el= where to have accompanying
characters that better denote what each key does (e.g. the plus sign
is for keys that continue the transient), then I am happy to apply
appropriate colours to those and reconsider the aforementioned.
** Semantic mappings for active arguments and values
:PROPERTIES:
:CUSTOM_ID: h:909053eb-0378-41f5-b32a-741fa53ba4a3
:END:
In various interfaces such as of ~eldoc-mode~ and =transient.el= there
are highlights for the current argument or argument value. These now
have corresponding semantic palette mappings and are thus styled
uniformly (and can be overridden accordingly). The mappings are:
- =bg-active-argument=
- =fg-active-argument=
- =bg-active-value=
- =fg-active-value=
** A semantic mapping for formulas in tables
:PROPERTIES:
:CUSTOM_ID: h:306889ed-64c8-414c-a744-14ea1e6b3e6d
:END:
The =prose-table-formula= applies to inline formula expressions in
plain text tables. Org mode uses those, as does the minor mode ~orgtbl-mode~.
The inline formula is meant to stand out from the rest of the table,
without exaggerations.
** Matching parentheses have semantic mappings for their foreground too
:PROPERTIES:
:CUSTOM_ID: h:4055d50e-0153-4576-bba5-fcdcdf039b10
:END:
By default, Emacs will highlight the matching (opening or closing)
delimiter when the cursor is next to it. This is useful in Lisp
programming modes, for example, as we can quickly get a sense of where
an expression starts and ends.
The themes now provide mappings for the foreground of those
delimiters. This means that users can either change the combination of
background and foreground or opt to only display a foreground value
for a more minimal look.
As always, the manual shows concrete examples:
<https://protesilaos.com/emacs/modus-themes#h:259cf8f5-48ec-4b13-8a69-5d6387094468>.
** Search highlights have their own semantic mappings
:PROPERTIES:
:CUSTOM_ID: h:df3879a4-e11d-47f0-9330-a2d51e999941
:END:
This makes it easier to differentiate their style on a per-theme
basis, which I do for all the Modus themes. It also gives users the
option to override the colours. The mappings:
- =bg-search-current=
- =bg-search-lazy=
- =bg-search-replace=
- =bg-search-rx-group-0=
- =bg-search-rx-group-1=
- =bg-search-rx-group-2=
- =bg-search-rx-group-3=
** Stylistic tweaks to ~modus-operandi-tinted~
:PROPERTIES:
:CUSTOM_ID: h:8885de5e-be29-45cc-a2e5-2dcb0866273d
:END:
The ~modus-operandi-theme~ uses a light ochre background, which gives
a warmer feel than the pure white background of ~modus-operandi~. To
better contribute to this warmth, I made some tweaks to common
elements:
1. The cursor has a red hue as before, but the value is a bit more
intense now. This makes it easier to spot in contexts where text is
already "warm", like close to an Org =TODO= keyword or in
programming mode comments.
2. All key bindings have a red hue instead of blue. We can notice the
effect in Help mode buffers that mention where a command is bound,
while using ~which-key-mode~, in =transient.el= buffers, in
minibuffer completion annotations, and more.
These are in addition to many nuances already built into ~modus-operandi-tinted~.
I hope that existing users will appreciate these tweaks. We anyway
have the option to override any entry in the palette, though I suggest
you give these a chance before enacting any changes.
** Stylistic tweaks to ~modus-vivendi-tinted~
:PROPERTIES:
:CUSTOM_ID: h:dc23c419-d87a-4973-9175-961af9e3051d
:END:
Same principle here as with the above set of changes. Namely:
1. The cursor uses a more intense magenta background to be easier to
spot.
2. Key bindings are purple instead of blue to better complement the
aesthetics of this theme.
3. The background highlight applied to matching parentheses (per ~show-paren-mode~) is grey-cyan instead of cyan.
Again, we can override everything but please try those for a little
while.
** The ~olivetti-fringe~ is visible when needed
:PROPERTIES:
:CUSTOM_ID: h:3c2d3f21-7686-4376-a3ec-82240b283eec
:END:
This is subject to the user option ~olivetty-style~, which can be set
to the value of =fancy= to produce a page-like effect.
Thanks to Dhavan Vaidya and Gautier Ponsinet for bringing this matter
to my attention on the now-discontinued mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3Cm2a5qzpi3y.fsf%40muon.local.mail-host-address-is-not-set%3E>
** A more subtle style for the ~consult-preview-insertion~ face
:PROPERTIES:
:CUSTOM_ID: h:8c6717d2-0488-4590-8083-52e081adf6f5
:END:
The default value of that face inherits from the ~region~ face. This
is fine in some cases, though not when the user calls
~consult-outline~ in a buffer with hidden text (e.g. Org folded
headings). There the background is applied to the entire heading's
surface area, which is too distracting while cycling through
completion candidates and inspecting the preview.
** Simpler ~imenu-list~ with four colours
:PROPERTIES:
:CUSTOM_ID: h:af7ec9f7-e7aa-4a05-a5a2-184d0d7143c6
:END:
The ~imenu-list~ defines two sets of faces which apply to same heading
levels but differ on whether the heading has subheadings or not.
Before, we would colourise those differently, which could be
confusing. Now they look the same, which is fine because the interface
has additional markup to show when subheadings are present.
Thanks to ltmsyvag for pointing this out in issue 95:
<https://github.com/protesilaos/modus-themes/issues/95>.
** Implicit buttons in Gnus are no longer underlined
:PROPERTIES:
:CUSTOM_ID: h:6b0cc04f-1a9b-436c-b11f-5446ea55b010
:END:
Gnus buttonises text that it considers actionable. The exact
functionality depends on the context, but it basically does stuff like
add a quick way to write a new message to a given email address. These
buttons can be mistaken for links, so I am removing their underline to
avoid any possible confusion.
** The ~message-separator~ face is less intense
:PROPERTIES:
:CUSTOM_ID: h:a049f538-2805-4379-8542-43dc6f990a2b
:END:
In message/email composition buffers, there is a line that
distinguishes headers from the body of the message. By default, it
reads =--text follows this line--= and will now have a subtle grey
background. The idea is to not stress the distinction between headers
and body, as this line's verbosity is already enough to call attention
to it when we add a subtle background.
** Recalibrated all "nuanced" background values
:PROPERTIES:
:CUSTOM_ID: h:ecb9c704-7615-4e42-8438-13e96c10588e
:END:
Each theme has a subset of slightly accented background named
=bg-{red,green,blue,yellow,magenta,cyan}-nuanced=. These have slightly
different values to be more consistent in terms of their intensity.
** The ~debbugs~ package is now supported
:PROPERTIES:
:CUSTOM_ID: h:67161fd3-f615-4856-b5df-99f5c0f2e5ee
:END:
Thanks to Gautier Ponsinet for sending me the relevant patch to my
personal email. I made further stylistic changes on top.
** The ~ztree~ package is covered as well
:PROPERTIES:
:CUSTOM_ID: h:c82277b9-abb9-4d1e-9912-14caf66af8d2
:END:
It produces a diff between two directories and thus needs appropriate
colours.
** Added support for ~xterm-color~ and ~rustic-mode~
:PROPERTIES:
:CUSTOM_ID: h:c262fdbe-49a5-480b-b0d1-6592f6e29879
:END:
These are basically reusing styles we already support for other
terminal emulators. Thanks to Tony Zorman for the contribution, which
was done in pull request 99: <https://github.com/protesilaos/modus-themes/pull/99>.
** Org checkboxes are monospaced when ~modus-themes-mixed-fonts~ is non-nil
:PROPERTIES:
:CUSTOM_ID: h:69dbe924-58b3-43e9-801c-35cf9ac8fffb
:END:
The user option ~modus-themes-mixed-fonts~ makes specing-sensitive
elements use a monospaced font (specifically, the font family of the
~fixed-pitch~ face). This lets the user set a more prose-friendly
style without visually breaking snippets that rely on fixed width
spacing. A prose-friendly style is done by making the default font a
proportionately spaced one, or by enabling ~variable-pitch-mode~ in
the current buffer.
For this case, we now cover Org checkboxes as well to avoid
misalignments in checklists.
Thanks to Gautier Ponsinet for discussing this with me via email and
sending the relevant patch.
** More code samples in the manual
:PROPERTIES:
:CUSTOM_ID: h:2ccb1b44-a36e-4ea1-9f24-9d080cdec02d
:END:
The manual documents everything about the customisation options
provided by the themes, as well as relevant do-it-yourself code
samples. I now include more examples and better explain how to hook
those either to the ~enable-theme-functions~ or the
~modus-themes-after-load-theme-hook~. If something is not clear or not
covered at all, please let me know and I will help you do what you
want.
** Miscellaneous
:PROPERTIES:
:CUSTOM_ID: h:2e5f0804-236d-49b5-9b2f-ecb4794b244b
:END:
- All =cl-= snippets are removed from the source code. We did not
really need them and I rewrote the code accordingly. This is not a
value judgement against Common Lisp patterns in Emacs Lisp (I do not
mind them): it is just a matter of removing a dependency for things
that can easily be done differently.
- The ~keycast-key~ inherits the ~bold~ face if the user option
~modus-themes-bold-constructs~ is set to a non-nil value.
- The ~read-multiple-choice-face~ now has a cooler hue than the one it
had before. This way it is not mistaken for a warning.
- The ~appt-notification~ face uses a foreground value that is better
suited for the modeline, where this indicator appears.
- The ~header-line-highlight~ draws a box around it. This makes the
mouse hover effect easier to spot.
- The ~shr-mark~ face is now covered as well. It uses an appropriate
background colour.
- The ~mct-highlight-candidate~ face is covered and has an appropriate
style for the minibuffer completions.
- The ~completions-highlight~ face (Emacs 29) is also supported to
ensure stylistic consistency between the minibuffer interfaces
covered by the themes.
- Flagged and deleted messages in ~mu4e~ and ~notmuch~ use different
hues to not conflate the two.
- Fixed the spelling of "colour" to "color" in the manual because core
Emacs uses the latter...
* 4.3.0
:PROPERTIES:
:CUSTOM_ID: h:4783bc29-3055-426d-9acb-51e4d0741871
:END:
** All themes except the tritanopia ones have a new hover colour
:PROPERTIES:
:CUSTOM_ID: h:b92b176e-3e9a-420d-bbbe-3c3e38b47027
:END:
The previous colour was not sufficiently distinct from what each theme
defines for the =bg-completion= palette entry (preview a palette with
=M-x modus-themes-preview-colors= or =M-x modus-themes-preview-colors-current=).
This would make it hard to spot the difference while, for example,
using ~vertico-mode~ in tandem with ~vertico-mouse-mode~.
Same principle for the difference between the mouse hover and lazy
isearch highlights (e.g. in Dired or Occur buffers).
Changing the hue here follows the same principle that underpinned the
redesign of the grey backgrounds for version 4 of the project:
depending on hardware capabilities, colour reproduction may not be
optimal, so we need to be more considerate with the choice of colour
values, erring on the side of caution.
The ~modus-operandi-tritanopia~ and ~modus-vivendi-tritanopia~ themes
are not affected by this initiative, as they already used highly distinct hues.
Thanks to Daniel Mendler for bringing this matter to my attention and
for testing the proposed alternatives. This was done via a private
channel and the information is shared with permission. Daniel is the
developer of ~vertico~, among many other excellent packages:
<https://github.com/minad>
** Japanese holidays have the expected style
:PROPERTIES:
:CUSTOM_ID: h:2de9cef6-c6f1-4c2e-97ce-46d8a7306bae
:END:
Japanese calendars style Saturdays uniquely and the Modus themes now
do the same for those who use the ~japanese-holidays~ package.
Saturdays show up in a blue colour (which changes to cyan for the
~modus-operandi-tritanopia~, ~modus-vivendi-tritanopia~ themes).
Each theme's palette has a new semantic colour mapping called
=date-holiday-other=, just in case we ever encounter another scenario
like this one (users can override any entry in the palette---consult
the manual for the technicalities).
Thanks to Olaf Meeuwissen for bringing this package to my attention
and showing me how traditional Japanese calendars style Saturdays.
This was done in issue 311 on the GitLab mirror:
<https://gitlab.com/protesilaos/modus-themes/-/issues/311>.
** Each theme has semantic colour mappings for terminal emulators
:PROPERTIES:
:CUSTOM_ID: h:f3ae786a-9e01-4363-ae98-898f2ad34f7b
:END:
These are used by ~ansi-term~, ~vterm~, and the like. The idea is to
empower users to differentiate background and foreground values,
should they ever encounter a need to do so (when in doubt, do
nothing).
By convention, terminal emulators use the same value for both
background and foreground, although this is not optimal with high
contrast themes because what works as a foreground does not
necessarily look nice as a background.
The default values of the new mappings retain the prior state, just to
not break existing configurations. Consider this a tacit user option
for those who really need it.
Thanks to Tony Zorman for reporting the problem that provided the
impetus for this change:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87fs4wforf.fsf%40hyperspace%3E>.
** All theme definitions conform with the latest standard for metadata
:PROPERTIES:
:CUSTOM_ID: h:2af0114f-b96a-4e89-ad2f-850d53538efa
:END:
Themes are expected to declare their background type and affinity,
such that the built-in command ~theme-choose-variant~ can do what it
describes (switch between related themes). I was already doing this,
though I had to make some adjustments. This is in response to Emacs
bug#65468: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65468>.
Thanks to Mauro Aranda for bringing the matter to my attention.
** Proper colours for the inline preview of the ~corfu~ top candidate
:PROPERTIES:
:CUSTOM_ID: h:89d40a68-7573-4994-9ecc-fea40c823472
:END:
The ~corfu-candidate-overlay~ package is used in tandem with the
~corfu~ package to create an inline preview of the first matching
candidate. Thanks to Nicolas Semrau for bringing this matter to my
attention in issue 89 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/89>.
** Context indicators for the mode-line or header-line (breadcrumb.el)
:PROPERTIES:
:CUSTOM_ID: h:dc391e85-650f-444e-b909-849d659921fb
:END:
I added support for the new ~breadcrumb~ package by João Távora. It
displays information about where we are in the given file, such as
under which Org heading or inside which function. The indicator can
be shown on the mode-line or the header-line. Either way, it will now
be legible and consistent with its surroundings.
** The new family of nerd-icons is covered by the themes
:PROPERTIES:
:CUSTOM_ID: h:0409d429-5307-43d6-9bf4-fabc958c2540
:END:
This is a new set of packages: ~nerd-icons~, ~nerd-icons-completion,
~nerd-icons-dired~, ~nerd-icons-ibuffer~. A popular package that uses
the Nerd icons is ~doom-modeline~, which the themes support as well.
** All icons look as intended again
:PROPERTIES:
:CUSTOM_ID: h:a01075c6-b931-4b35-bdbd-2d1223101560
:END:
Some faces from the ~all-the-icons~ package were not configured
because I accidentally changed their name from something like
~all-the-icons-red-alt~ to ~all-the-icons-red-warmer~. I did that
while renaming the colours defined in each theme's palette, to make
them more meaningful ("warmer red" can hint at something whereas "alt
red" is more abstract).
** Corrected the documentation about custom Org faces
:PROPERTIES:
:CUSTOM_ID: h:5c254346-370e-4510-bcc7-70a1cca2c5a0
:END:
The Modus themes manual shows how to configure arbitrary TODO keywords
to inherit the style of an arbitrary face (get the list of faces
present in your Emacs with =M-x list-faces-display=). The previous
value I used was faulty. It now is as intended. Thanks to
soaringbird for reporting the issue on the mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3CNXPVkVk--3-9%40tuta.io%3E>.
** The colours used by =avy= are better for users with tritanopia
:PROPERTIES:
:CUSTOM_ID: h:3605693e-bd6d-40a0-a1d4-199684c89081
:END:
I changed the sequence of colours displayed by commands such as
~avy-goto-char-timer~ such that each individual background does not
blend with the ones adjacent to it, while respecting the overall needs
of a tritanopia-friendly design. I also tweaked the colour values to
achieve the desired result. The backgrounds remain distinct from
their context but now also work harmoniously together.
** The =bg-dim= palette entry is marginally brighter in all Modus operandi variants
:PROPERTIES:
:CUSTOM_ID: h:8a3cb4f1-e7f8-48f1-832c-27e64b126b2d
:END:
After extensive testing and side-by-side comparisons, I have concluded
that the marginal increase in brightness improves the affected
interfaces.
The =bg-dim= background is used, among others, in the header-line, the
popup of the ~company~ and ~corfu~ packages, as well as the Org source
blocks (when the user option ~modus-themes-org-blocks~ is configured
appropriately).
** The "intense" palette override preset has new colours for tables and prose metadata
:PROPERTIES:
:CUSTOM_ID: h:3a990310-337c-457f-8f40-1af6d1b557f6
:END:
This concerns the ~modus-themes-preset-overrides-intense~ (refer to
its documentation on how to use it). The primary target of these
changes is Org mode and the overall effect is subtle. The previous
colours did not combine nicely with all structural elements. For
example, Org clocktables would obscure timestamps by being the same
colour as them, while the table formula would not stand out. These
styles did not fit into the concept of "intense" colours.
** The "warmer" palette override preset has more legible strings
:PROPERTIES:
:CUSTOM_ID: h:64cbd701-1344-48cc-8bcf-fc9712438013
:END:
The ~modus-themes-preset-overrides-warmer~ uses a more prominent warm
green value for strings in programming modes. The effect is subtle,
though it fits in better with the overall aesthetic of these palette
overrides.
** Org document keywords like =#+author= are optionally monospaced
:PROPERTIES:
:CUSTOM_ID: h:096b75ec-802c-43e4-81ed-6db92b45654c
:END:
When the user option ~modus-themes-mixed-fonts~ is non-nil, all Org
document keywords will be rendered with the ~fixed-pitch~ face. This
ensures consistency between keywords such as =#+author= and "meta
lines" like =#+texinfo=. Thanks to user fluentpwn for the change: it
is one line and thus the author does not need to assign copyright to
the Free Software Foundation.
** Git commit summary lines have a more precise style
:PROPERTIES:
:CUSTOM_ID: h:2aecd902-3a0b-4544-98f4-dbb42cbad672
:END:
This concerns the first line in a Git commit message, as seen while
working with the ~magit~ package. Same principle for the ~log-edit~
buffer used by the built-in VC framework. Before, I was hardcoding a
blue colour value, whereas now I apply the ~success~ face. The
~success~ face is designed to contrast with the ~warning~ face that is
used to show overlong summaries. Furthermore, the added indirection
makes it possible to particularise the colour value, which I do for
the tritanopia themes that cannot use blue.
** Miscellaneous
:PROPERTIES:
:CUSTOM_ID: h:7391fd7d-6e70-4419-a8d6-f34d9ae075b1
:END:
- Removed explicit support for the built-in ~css-mode~. Its default
faces are decent. They inherit from standard font-lock faces that
the themes already cover.
- Recalibrated wordwise ("refined") diffs for deuteranopia. The ~modus-operandi-deuteranopia~ and ~modus-vivendi-deuteranopia~ have
a little bit more intense colour values applied to wordwise, else
"refined", diffs. These concern removed lines. The effect is
visible while using ~magit~ or the built-in ~diff-mode~.
- Backported emacs.git commit =4cf33b6bd02b868ebbf112da7926d7c3c64517ce=.
It removed the space from the front matter of the =modus-themes.org=
file (i.e. the manual) because the Org export did not produce the
right results, per Emacs bug#64548. Thanks to Stephen Berman for
reporting the issue and making the requisite change.
- Added support for the ~erts-mode~. Thanks to Kevin Fleming for
informing me about this built-in mode. This was done in issue 85 on
the GitHub mirror: <https://github.com/protesilaos/modus-themes/issues/85>.
- Fixed a typo in the ~modus-themes-preset-overrides-intense~ doc
string. Thanks to Nicolas Semrau for bringing this matter to my
attention. It was done in issue 90 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/90>.
- Made all commands that prompt for a theme (~modus-themes-select~, ~modus-themes-preview-colors~) apply the =theme= category to the
available candidates. This allows the user to target said category
to affect the relevant functions. For example, to set completion
styles with ~completion-category-overrides~ or to define a custom
annotation function with the ~marginalia~ package.
- Added support for new ~appt-notification~ face (Emacs 30). Change
upstream by me.
* 4.2.0
:PROPERTIES:
:CUSTOM_ID: h:29370d83-23c4-415b-afbf-ad85d4296c86
:END:
** I won a Google award for the Modus themes
:PROPERTIES:
:CUSTOM_ID: h:1ffc8660-511d-4fa8-aff4-11da8246a186
:END:
Report here: <https://protesilaos.com/codelog/2023-05-25-emacs-google-award/>.
This is not a "change" per se, but it is worth documenting here. It
shows how important accessibility can be in empowering people to use
their computer and, in our case, to exercise their software freedoms.
The Modus themes tend to one aspect of accessibility. They do not
exhaust the topic, though they should at least raise awareness about
the significance of tending to the usability needs of everyone. The
effort I put into documenting the themes (and my other packages)
should be understood in this light as a means of helping people enjoy
their software freedom by learning how to use and extend the program
in question.
** New tritanopia-optimised themes
:PROPERTIES:
:CUSTOM_ID: h:b92706b0-9d53-4015-8916-9db3c0c87068
:END:
I have created a pair of light and dark themes that are intended for
people with blue-yellow colour deficiency (tritanopia). These are
~modus-operandi-tritanopia~ (light) and ~modus-vivendi-tritanopia~
(dark). Screenshots of all the Modus themes are available on my
website: <https://protesilaos.com/emacs/modus-themes-pictures>.
The entire collection is now described in the manual as follows:
#+begin_quote
The Modus themes consist of eight themes, divided into four subgroups.
- Main themes :: ~modus-operandi~ is the project's main light theme,
while ~modus-vivendi~ is its dark counterpart. These two themes are
part of the project since its inception. They are designed to cover
a broad range of needs and are, in the opinion of the author, the
reference for what a highly legible "default" theme should look
like.
- Tinted themes :: ~modus-operandi-tinted~ and ~modus-vivendi-tinted~
are variants of the two main themes. They slightly tone down the
intensity of the background and provide a bit more color variety.
~modus-operandi-tinted~ has a set of base tones that are shades of
light ochre (earthly colors), while ~modus-vivendi-tinted~ gives a
night sky impression.
- Deuteranopia themes :: ~modus-operandi-deuteranopia~ and its
companion ~modus-vivendi-deuteranopia~ are optimized for users with
red-green color deficiency. This means that they do not use red and
green hues for color-coding purposes, such as for diff removed and
added lines. Instead, they implement colors that are discernible by
users with deueteranopia or deuteranomaly (mostly yellow and blue
hues).
- Tritanopia themes :: ~modus-operandi-tritanopia~ and its counterpart
~modus-vivendi-tritanopia~ are optimized for users with blue-yellow
color deficiency. The idea is the same as with the deuteranopia
variants: color coding relies only on hues that are accessible to
people with tritanopia or tritanomaly, namely, shades of red and
cyan.
#+end_quote
** Recalibrated the "graph" colours in all themes
:PROPERTIES:
:CUSTOM_ID: h:60bb2797-2db6-4d47-9d27-7d1f32291707
:END:
The new palette subset improves the contrast of all the relevant
colours when presented side-by-side. These are most notably used by
the ~org-habit~ consistency graph, which is displayed in the Org
agenda. The deuteranopia and tritanopia themes have their own bespoke
colours for this purpose, due to their specific requirements for
colour coding (e.g. they cannot use green).
** Faces or face groups
:PROPERTIES:
:CUSTOM_ID: h:4b68159e-d998-4781-b202-74a3dcc8ae8e
:END:
- Introduced a subtle 3D effect for clickable buttons, replacing the
previous 2D design. I realised the flat style creates ambiguity
between the button and the text fields. This happens, for example,
with =M-x customize-variable= for ~org-capture-templates~ which has
lots of button and text field combinations. The added sense of
depth helps with the usability of these buttons because it makes
them unambiguous. Personally, I prefer the 2D approach, but here we
have a trade-off between usability and aesthetics. According to
what I state in the manual:
#+begin_quote
If there arises an inescapable trade-off between usability and
stylistic considerations, we will always opt for the former.
#+end_quote
- Refashioned the ~whitespace-mode~ to be much more subtle and added
the concomitant semantic colour mappings.
The previous style involved the use of a dim grey background for
each invisible character. While this is was good to spot invisible
characters quickly, it was a major hindrance for users who want to
run ~whitespace-mode~ at all times (e.g. for the Python programming
language which is space-sensitive).
We thus remove the backgrounds by default but provide the option to
reinstate them via palette overrides (as documented at length in the
manual). To this end, we have two new semantic colour mappings for
ordinary space, its invisible characters, as well as space errors.
Thanks to Christian Tietze and Oliver Epper for their feedback in
issue 80 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/80>.
- Applied a more subtle background for faces ~menu-bar-mode~, ~tool-bar-mode~, ~scroll-bar-mode~. They do not need to stand out
so much because the toolkit already takes care of that. Also, we do
not want to dillute the semantic value of either ~bg-tab-bar~ or ~fringe~ palette colour mappings that I was wrongly using before in
this context. Note that those faces may not apply, depending on the
underlying tool kit. For example, I encounter them with the Lucid
build of Emacs, though not with the GTK one.
- Fix the critical typo of 'widget-buton', which prevented the actual ~widget-button~ face from being affected by the themes. Thanks to
Steve Downey for pointing it out in issue 73 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/73>.
- Added support for the ~disk-usage~ package. It is made to look like
Dired, to the extent possible. Thanks to Nacho Barrientos for the
patch: <https://lists.sr.ht/~protesilaos/modus-themes/patches/39822>.
The change is small and does not require copyright assignment to the
Free Software Foundation.
- Made the ~eglot-diagnostic-tag-unnecessary-face~ look like a
warning. By default it inherits the ~shadow~ face, which makes it
counter-intuitive as it dims the text instead of bringing it to our
attention. The intent of ~eglot-diagnostic-tag-unnecessary-face~ is
to highlight unused symbols, so this is better presented as a
warning.
Thanks to Augusto Stoffel for bringing this matter to my attention.
This was done via a private channel and the information is shared
with permission.
- Changed the ~smerge-markers~ to inherit from ~diff-header~ instead
of ~diff-heading~. Thanks to Steve Downey for the contribution.
This was done in pull request 74 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/pull/74>. The change
is small and does not require copyright assignment to the Free
Software Foundation.
- Added support for the ~jinx~ package. This was originally done by
Tomasz Hołubowicz in pull request 71 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/pull/71>. The change
is small and does not require copyright assignment to the Free
Software Foundation. I then modified it to make the underlines look
like warnings instead of errors. This is because of how the package
works: it automatically highlights misspellings in the visible
portion of the buffer. There are cases where this results in a very
intense presentation, which can be distracting. We want to reduce
the overall intensity and not draw too much attention to those
highlights.
- Extended coverage of Org to the new ~org-agenda-calendar-daterange~
face (part of Org version 9.7). Thanks to Gautier Ponsinet for the
patch, which I received via a private channel. The change is small
and does not require copyright assignment to the Free Software
Foundation. In addition to this, I introduced a new semantic colour
mapping in the themes' palette called ~date-range~. This can be
used with the palette overrides, which are documented at length in
the manual (there are lots of copy-pastable examples as well).
- Supported all of the new faces of the built-in ~proced~ package.
These are part of Emacs 29 and make the ~proced~ buffers more
colourful, subject to the user option ~proced-enable-color-flag~.
As always, the themes strive to avoid exaggerations, meaning that I
apply colour with restraint: not all faces need to stand out.
- Included the ~rst-mode~ in the list of explicitly supported
packages, making its heading look like those of Org, Markdown, etc.
Thanks to David Edmondson for the patch:
<https://lists.sr.ht/~protesilaos/modus-themes/patches/40625>. I
believe David has already assigned copyright to the Free Software
Foundation, though this patch is small anyway.
- Covered all the new faces of the built-in ~flymake~ package. These
concern the inline feedback messages (Emacs 30) as well as those
that appear in the echo area (Emacs 29). The former are subject to
the user option ~flymake-show-diagnostics-at-end-of-line~.
- Reduced the intensity of the ~which-key~ prefix descriptions. Those
are the keymaps that displayed by ~which-key~ to hint that typing
the given key will open a new ~which-key~ page with more keys.
- Configured new ~vundo-saved~ and ~vundo-last-saved~ faces of the ~vundo~ package. They are designed to be easy to read, without
going over-the-top. Thanks to Nicolas Semrau for bringing this
matter to my attention in issue 79 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/79>.
- Removed the deprecated ~consult-preview-cursor~ face and made the
requisite adjustments to the ~consult~ faces. This was done in
commit =267b0c9= of the Consult Git repository. Discussed here:
<https://github.com/minad/consult/issues/764#issuecomment-1537491625>.
- Instructed the ~shr-selected-link~ face of the built-in ~shr~
package to use a "mark selection" style instead of the semantically
incorrect "intense red" it had before. This change is helpful for
those who override the palette of their Modus theme of choice, while
it also allows us to have varied colours depending on the
requirements of each theme (e.g. deuteranopia/tritanopia compared to
the defaults).
- Did the same as above, mutatis mutandis, for the faces ~transient-disabled-suffix~, ~web-mode-error-face~, ~erc-dangerous-host-face~, ~aw-minibuffer-leading-char-face~, ~binder-sidebar-highlight~, ~binder-sidebar-missing~, ~image-dired-thumb-flagged~, ~image-dired-thumb-mark~, ~info-menu-star~, ~rainbow-delimiters-mismatched-face~, ~evil-ex-substitute-matches~, ~iedit-occurrence~, ~iedit-read-only-occurrence~, ~pgtk-im-0~, ~dired-narrow-blink~.
- Enhanced the ~image-dired~ mark faces with a box border, as the use
of a background alone can be obscured by the underlying image
thumbnail, depending on its figures/colours.
- Removed the backgrounds from the ~powerline-evil~ faces and
simplified their overral presentation in the interest of
maintainability. The old styles were hard to predict and test.
There could easily be conflicts, such as if the user would override
the colours of the mode line.
- Ensured that ~diary~ and ~holiday~ colours are distinct and legible,
without being too intense.
** Changes to the manual or other documentation
:PROPERTIES:
:CUSTOM_ID: h:d3c12dd0-4231-420b-a212-b6bd571c5c34
:END:
- Updated the doc string of the primary customisation group defined by
the themes to reflect the support for the case of tritanopia.
- Included links to the web page of the manual and the one with the
sample pictures in the customisation groups. Those links appear in
the various Custom UI buffers.
- Introduced an annotation function for all commands that involve
minibuffer completion. The annotations display the one-line
description of each theme, making it easier for a user to pick their
preferred choice (e.g. when using the ~modus-themes-select~
command).
- Defined semantic colour mappings for "marks". These are used by ~dired~, ~trashed~, ~proced~, and others. These is no change to the
default appearance of what users are already familiar with, though
it is now possible to override those styles.
- Complemented the subset of semantic colour mappings for
errors/warnings with "prominent" variants. Those employ a
background and foreground combination. They are used in all sorts
of contexts, such as for fringe errors (~flymake~, ~flycheck~, ...),
~query-replace~, ~isearch-fail~, and others.
- Wrote sample code on how to add "padding" to the Emacs frame and the
space between the Emacs windows. This makes for a presentation that
some users find easier to work with.
- Corrected the sample code for ~git-gutter~ to use the appropriate
symbols from the theme palette. Thanks to Christian Tietze for the
patch: <https://lists.sr.ht/~protesilaos/modus-themes/patches/40354>.
The change is small and does not require copyright assignment to the
Free Software Foundation.
- Removed ~moody~ from the list of packages explicitly supported by
the themes. We stopped supporting it since version 4 that removed
the relevant user option for the mode line. The idea is that the
mode line is better handled by the user without interference from
the theme, due to the number of options available (and how brittle
those can be when interacting with unpredictable face definitions).
Thanks to Nicolas De Jaeghere for reminding me to remove ~moody~
from the manual:
<https://lists.sr.ht/~protesilaos/modus-themes/%3Cypi9jzyclqxy.fsf%40gmail.com%3E#%3C87jzybdgg1.fsf@dejaeghe.re%3E>.
** Miscellaneous
:PROPERTIES:
:CUSTOM_ID: h:7240990a-2b4d-442c-a15c-84c8d8b26622
:END:
- Added two new preset palette overrides to make the overall
presentation "warmer" or "cooler". Those are called ~modus-themes-preset-overrides-warmer~ and ~modus-themes-preset-overrides-cooler~, respectively. The manual
explains how those presets can be used. I suggest the user does not
add such overrides if they intend to load any of the deuteranopia or
tritanopia themes, due to the specific requirements of their design.
- Refined the deuteranopia yellows for warnings, errors, and comments.
These otherwise slight adjustments make it considerably easier to
tell apart distinct elements that may be positioned close together.
- Tweaked the deuteranopia semantic colour mappings for emails. The
subject line use a more appropriate colour value, while level 3
quotes stand out a bit more than they did before, without being
needlessly intense.
- Arranged for the ~modus-themes-load-theme~ function return the value
of the =THEME= argument it accepts. The intent is to allow other
functions that call this one to capture the return value for their
purposes (such as with a ~let~ binding). Thank to Oliver Epper for
the feedback in issue 78 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/78>.
* 4.1.0
:PROPERTIES:
:CUSTOM_ID: h:d028f117-8a74-4c0c-b838-9f6bf2b43c19
:END:
** Recursive semantic colour mapping
:PROPERTIES:
:CUSTOM_ID: h:262e2f5f-4db0-4549-a5ba-4e57cd2edc6a
:END:
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
:PROPERTIES:
:CUSTOM_ID: h:6ba1437f-e55f-4c3a-9c03-b0035293b4a2
:END:
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
:PROPERTIES:
:CUSTOM_ID: h:5af072da-38f6-44d0-9342-e799f0196006
:END:
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.
This happens when the theme is loaded with the commands
~modus-themes-toggle~ and ~modus-themes-select~, or via Lisp with the
function ~modus-themes-load-theme~.
Users who need to run multiple themes can set this option to a nil
value. (Personally, I use minor modes for such stylistic bundles and
never have to worry about ~(mapc #'disable-theme custom-enabled-themes)~.)
Thanks to Tony Zorman for the feedback on the mailing list, which led
me to the introduction of this user option:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C874jtew0gp.fsf%40hyperspace%3E#%3C87bkne84d2.fsf@hyperspace%3E>.
** Renamed the named colours for bg-{added,changed,removed}-intense
:PROPERTIES:
:CUSTOM_ID: h:d43ef5cb-10dd-4c33-9429-2289a5fb2506
:END:
They are now called ~bg-added-fringe~, ~bg-changed-fringe~,
~bg-removed-fringe~. Please update any palette overrides to reflect
this renaming.
** Documented how to override diffs for more optional combinations
:PROPERTIES:
:CUSTOM_ID: h:220d4361-7245-4632-998e-c0e2ee3b5f7d
:END:
The manual includes details (with copy-pastable code) on how to
achieve foreground-only diffs and/or how to have red+blue diffs
instead of the default red+green or the deuteranopia yellow+blue.
Thanks to Andrew Tropin for requesting this feature. We used to
provide this style in earlier versions of the themes, but now it is
much more flexible. Andrew's request was done via a private channel
and the information is shared with permission.
[ Since we are here, also thanks to Andrew for keeping the Guix
package of the Modus themes up to date. ]
** Stylistic changes
:PROPERTIES:
:CUSTOM_ID: h:fdcff629-22c1-4203-9104-4f732c59f731
:END:
- Guaranteed consistency between all of the line-related faces of the
~consult~ package. We use the ~shadow~ face in all interfaces where
line numbers are contextual information (Occur, Grep,...). With
Consult, this was not the case for commands like ~consult-line~.
Thanks to Daniel Mendler (also known as @minad) for bringing this
matter to my attention:
<https://lists.sr.ht/~protesilaos/ef-themes/%3Cb03413a6-cb77-615d-145d-db4eb710bfca%40daniel-mendler.de%3E>.
- Refined all diff colours for fringes and reduced the saturation for
added lines in ~modus-operandi-deuteranopia~, ~modus-vivendi-deuteranopia-theme~.
Thanks to Andrew Tropin for showing me some usability issues with
the previous styles. This was done via a private channel and the
information is shared with permission.
- Instructed the ~dashboard~ icons to retain their underlying colour.
The default value of the ~dashboard-items-face~ made all icons use
the same colour, detracting from their distinctiveness. Thanks to
Thanos Apollo for bringing this matter to my attention. It was done
via a private channel and the information is shared with permission.
- Amplified the intensity of the =#+begin_src= text when the user
option opts for ~(setq modus-themes-org-blocks 'gray-background)~.
The text is now easier to discern. That user option makes the
inside of the block have a gray background and the begin/end lines
to have a more intense gray, giving off a "blocky" impression.
- Made the ~compilation-warning~ face also inherit the
~modus-themes-bold~ face. This means that it responds to the value
of the user option ~modus-themes-bold-constructs~, the same way the
other compilation-related mode line faces do. Thanks to Manuel
Giraud for informing me about the inconsistency in
~compilation-warning~. This was done via a private channel and the
information is shared with permission.
- Calibrated the hueness of the "nuanced" backgrounds in the
~modus-operandi-tinted~ and ~modus-vivendi-tinted~ themes. These
tweaks are necessary to retain thematic consistency.
- Reset ~mu4e-header-highlight-face~ to its intended style. I made a
mistake before: I did not want the ~highlight~ face to be used in
this case as it is too intense. Sorry!
- Toned down the highlight line of the ~ctrlf~ and ~swiper~ packages.
I mistakenly used the ~highlight~ before, which is too intense for
the purposes of an ancillary background colour.
- Applied "nuanced" backgrounds to the tinted Org blocks. This fixes
an error of mine where I amplified the background colouration of Org
blocks. This concerns the case where the user option
~modus-themes-org-blocks~ has a =tinted-background= value. Thanks
to Mark Bestley for informing me about this in issue 60 on the
GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/60#issuecomment-1374530488>.
- Removed the hardcoding of the ~italic~ style in three faces, opting
instead to make them subject to the user option ~modus-themes-italic-constructs~.
The faces are ~marginalia-documentation~, ~markup-attribute-face~,
and ~org-agenda-calendar-sexp~.
- Tweaked the Org agenda deadline and today schedule to use a bold
weight only when the user option ~modus-themes-bold-constructs~ is
set to a non-nil value. Thanks to Marko Kocic for reporting an
issue that brought this matter to my attention:
- <https://lists.sr.ht/~protesilaos/modus-themes/%3C35588839.256749.1673272214728%40office.mailbox.org%3E>
- <https://lists.sr.ht/~protesilaos/modus-themes/%3C874jszvk5g.fsf%40protesilaos.com%3E>
- <https://lists.sr.ht/~protesilaos/modus-themes/%3C87ilhfu101.fsf%40protesilaos.com%3E>
- Enforced the main foreground colour in the faces =highlight= and =secondary-selection=. This should have always been there to avoid
awkward colour combinations. I realised it was missing after
corresponding with Edgar Vincent on a relevant topic:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C878ri95h1q.fsf%40posteo.net%3E#%3C87ilhc7usc.fsf@posteo.net%3E>.
- Made the ~eglot-mode-line~ face conditionally bold, by subjecting it
to the user option ~modus-themes-bold-constructs~.
- Ensure that the background of the ~company~ package's popup is the
same as that of the ~corfu~ package. This is a subtle neutral
value.
- Fixed the hue of the ~org-habit~ "ready" faces. It should be green
and I made a mistake here. The ~modus-operandi-deuteranopia~ and ~modus-vivendi-deuteranopia~ themes do change the underlying hues
though, as green is not suitable for them.
- Simplified the ~keycast~ faces so that (i) they do not use a =:box=
attribute that can look awkward in some cases and (ii) the name of
the given command is not colourised to avoid exaggerations with the
use of colour.
- Made the ~powerline-active1~ face inherit from ~mode-line~ instead
of ~mode-line-active~. The latter only exists in newer versions of
Emacs and we do not want to make the themes break in older versions.
Thanks to TitusMu for identifying this and reporting it in issue 64 on
the GitHub mirror: <https://github.com/protesilaos/modus-themes/issues/64>.
- Decoupled all ~ediff~ faces from their ~diff-mode~ counterparts.
Ediff does not depend on ~diff-mode~, so we want to make each set of
faces stand on its own. Thanks to Bernd Rellermeyer for pointing
out this implicit dependency in issue 68 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/68>.
** Miscellaneous
:PROPERTIES:
:CUSTOM_ID: h:14d1f1b0-00e0-4275-a06c-9e34daf6411a
:END:
- Improved the clarity and robustness of the code that does the work
of ~modus-themes-list-colors~.
- Refined the colour value of the =blue-warmer= named colour for all
the light themes. It is a tiny bit darker than before.
- Introduced a ~t~ fallback value for the user option ~modus-themes-completions~. It makes it easier to apply the same
styles for the selection line and matching characters.
- Documented how to not extend the active region background.
- Explained how to make tabs more or less colourful by using palette
overrides.
- Removed obsolete and redundant statements from the documentation the
user option ~modus-themes-completions~. There was (i) an outdated
reference to the =background= value, which is no longer supported,
and (ii) a statement about the standard Completions' buffer that was
not useful. Thanks to Rudolf Adamkovič for informing me about this:
<https://lists.sr.ht/~protesilaos/modus-themes/%3Cm2tu1211qz.fsf%40me.com%3E>.
- Rephrase the statement ="*Completions* buffer"= in the documentation
in the interest of clarity. Thanks to Rudolf Adamkovič for the
suggestion:
<https://lists.sr.ht/~protesilaos/modus-themes/%3Cm2tu1211qz.fsf%40me.com%3E#%3Cm2eds43htz.fsf@me.com%3E>.
- Updated the sample configuration of the themes with ~use-package~ in
the interest of simplicity. Thanks to Sergey Nichiporchik for the
contribution. Sergey's contribution is within the ~15 line limit
and thus does not require copyright assignment to the Free Software
Foundation.
This was done in merge request 59 on the GitLab mirror:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/59>.
The prepatory discussion took place in issue 310 on the same mirror:
<https://gitlab.com/protesilaos/modus-themes/-/issues/310>.
Weeks later I further simplified the relevant samples for the sake
of uniformity with the generic package setup. Thanks to Zoltan
Kiraly for informing me about the fact that the ~:bind~ keyword
delays the load of the package until the given command is invoked:
<https://github.com/protesilaos/modus-themes/pull/67>.
Streamlining the configuration makes it easier for me to propose one
set of basic configurations without the need to know what a
configuration macro is doing behind the scenes.
- Fixed an example colour in the documentation. Thanks to Russell Sim
for spotting the error of me using =bg-blue= instead of =bg-blue-intense=:
<https://lists.sr.ht/~protesilaos/modus-themes/%3Cyger0wa9gsn.fsf%40simopolis.xyz%3E>.
- Defined the missing =modus-themes-nuanced-{red,green,yellow,blue,magenta,cyan}= faces.
Those are used internally to avoid repetition, though users can also
rely on them for their personal configurations (same for all other
Modus faces).
- Improved the documentation on how to have a borderless mode line
style by using the palette overrides.
- Updated the manual's entry on the ~pdf-tools~ backdrop to make it
use the new conventions that have been in place since version 4 of
the themes. Thanks to Utkarsh Singh for the patches:
<https://lists.sr.ht/~protesilaos/modus-themes/patches/37902>.
- Add an explicit notice that the version of the themes that is built
into Emacs must use the ~require-theme~ function instead of the
familiar ~require~. Built-in themes are not considered "code", due
to old conventions, and are not part of the ~load-path~ that ~require~ reads from. This is not up to the theme to decide.
Interested users must simply know about this important technicality.
Thanks to Koen van Greevenbroek for reporting the problem that
helped me identify this issue:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C31038fd76868fa3d07c9a429dfed8fd6ac374bb8.camel%40posteo.net%3E>.
- Clarified the wording of the ~modus-themes-with-colors~ setup for
custom faces. It explains when this macro should be called. Thanks
to user bangedorrunt for the feedback in issue 59 on the GitHub
mirror: <https://github.com/protesilaos/modus-themes/issues/59>.
* 4.0.0
:PROPERTIES:
:CUSTOM_ID: h:cd353ccc-daf5-4ee5-885a-b3f21be92b66
:END:
This is the biggest release in the history of the project.
Previously, a new version would consist of about 100 commits to the
Git repository. This one includes 400+ of them in the span of one
month. The out-of-the-box looks of the themes are largely the same as
before, though I have made a lot of internal changes that affect how
the themes are instantiated and customised.
As part of this development cycle, I produced publications informing
users of the upcoming changes, while demonstrating the new feature of
overriding the colour palette and its semantic mappings.
- 2022-12-03 Emacs: breaking changes coming to 'modus-themes' version 4 :: <https://protesilaos.com/codelog/2022-12-03-modus-themes-v4-development/>
- 2022-12-07 Emacs: change colour values and mappings in Modus themes version 4 :: <https://protesilaos.com/codelog/2022-12-07-modus-themes-4-colour-values-mappings/>
- 2022-12-17 Emacs: modus-themes version 4 demo [video] :: <https://protesilaos.com/codelog/2022-12-17-modus-themes-v4-demo/>
- 2022-12-28 Emacs: note for MELPA or Git users of the Modus themes ahead of version 4 :: <https://protesilaos.com/codelog/2022-12-28-note-modus-themes-4-melpa/>
I did this in the hope of preparing users for the refactored Modus
themes, though I understand that not everyone has had the chance to
consult those entries. The general idea is that *old custom code will
not work* and most user options are either removed or confined to a
more precise scope.
Custom code will not work because the named colours of the palettes
have changed. Many user options are made redundant by the new
overrides' system. Specifically, if an option pertains to
colouration, it is now done via overrides instead of the old method of
me hardcoding styles (e.g. for stuff like "rainbow" headings).
More details below. This is a long entry. Please take your time to
study it before upgrading to the new version of the themes.
** There now are six Modus themes for more legibility needs
:PROPERTIES:
:CUSTOM_ID: h:f305dd08-a713-4369-a16d-af9403ab6c22
:END:
Quoting from the manual's "Overview" section:
#+begin_quote
The Modus themes consist of six themes, divided into three subgroups.
- Main themes :: ~modus-operandi~ is the project's main light theme,
while ~modus-vivendi~ is its dark counterpart. These two themes are
part of the project since its inception. They are designed to cover
a broad range of needs and are, in the opinion of the author, the
reference for what a highly legible "default" theme should look
like.
- Tinted themes :: ~modus-operandi-tinted~ and ~modus-vivendi-tinted~
are variants of the two main themes. They slightly tone down the
intensity of the background and provide a bit more color variety.
~modus-operandi-tinted~ has a set of base tones that are shades of
light ochre (earthly colors), while ~modus-vivendi-tinted~ gives a
night sky impression.
- Deuteranopia themes :: ~modus-operandi-deuteranopia~ and its
companion ~modus-vivendi-deuteranopia~ are optimized for users with
red-green color deficiency. This means that they do not use red and
green hues for color-coding purposes, such as for diff removed and
added lines. Instead, they implement colors that are discernible by
users with deueteranopia or deuteranomaly (mostly yellow and blue
hues).
#+end_quote
All six themes will be included in Emacs 30 (~modus-operandi~ and
~modus-vivendi~ are in Emacs since August 2020). I asked about it on
the emacs-devel mailing list and received the approval of Eli
Zaretskii, one of the Emacs maintainers. The full thread:
<https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00834.html>.
*** New command to select one of the Modus themes
:PROPERTIES:
:CUSTOM_ID: h:e4f011c4-46d3-4e4f-ad3e-9a609ef8bd5e
:END:
The ~modus-themes-select~ command uses minibuffer completion to load
one of the six themes in the collection. Loading a Modus theme
disables all other Modus themes.
NOTE that Emacs can load multiple themes, which typically produces
undesirable results and undoes the work of the designer. Use the
~disable-theme~ command if you are trying other themes beside the
Modus collection.
*** New user option to specify themes to toggle
:PROPERTIES:
:CUSTOM_ID: h:c4efdaca-505b-4724-81b4-4a5340cbcaba
:END:
The ~modus-themes-to-toggle~ is a variable that affects the command
~modus-themes-toggle~. By default, the toggling happens between the
~modus-operandi~ and ~modus-vivendi~ themes, as was always the case.
Though with the addition of new themes, it is possible to change this
to something like:
#+begin_src emacs-lisp
(setq modus-themes-to-toggle '(modus-operandi-deuteranopia modus-vivendi-deuteranopia))
#+end_src
If ~modus-themes-to-toggle~ does not specify two Modus themes, the
~modus-themes-toggle~ command will prompt with completion for a theme
among the collection (this is practically the same as the aforementioned
~modus-themes-select~ command).
** Colour palettes and their overrides are much more powerful
:PROPERTIES:
:CUSTOM_ID: h:c20673d3-d992-4827-bd24-80329962dc8e
:END:
In previous versions, there were options to override colour values.
Those were difficult to use as they (i) required expertise on picking
the correct values and (ii) it was not clear which colour was used
where.
The new version broadens the colour palette to include *named colours*
and *semantic colour mappings*. Named colours are associations
between a symbol and a colour value, such as =(blue-warmer "#354fcf")=.
While semantic colour mappings apply those named colours to specific
constructs such as =(heading-2 yellow-faint)= for all level 2 headings.
What this means is that overrides can now be targeted at semantic
mappings as well to refashion practically every aspect of the themes.
The manual provides lots of examples that can be copied and used
directly. For example, it is possible to change the sequence of
colours in headings so that, say, there is a colour-coding that
denotes depth. Links to relevant entries are included in this
document.
The ~modus-themes-common-palette-overrides~ user option contains
entries that are shared between all the themes. While there also
exist theme-specific options such as ~modus-operandi-palette-overrides~.
For technical insight into the palette overrides, consult the manual:
<https://protesilaos.com/emacs/modus-themes#h:34c7a691-19bb-4037-8d2f-67a07edab150>.
For practical examples check "Stylistic variants using palette
overrides" and its subsections:
<https://protesilaos.com/emacs/modus-themes#h:df1199d8-eaba-47db-805d-6b568a577bf3>.
** Preset overrides for faint or intense colouration
:PROPERTIES:
:CUSTOM_ID: h:5ba76bb2-9ca8-4202-aca3-31aaca239d94
:END:
The palette overrides are comprehensive and can be tweaked in a
detailed way. Still, users may prefer to use the presets for a
"faint" or "intense" style. These presets showcase the new feature by
styling elements that were previously not subject to configuration.
They also provide the convenience of a common set of stylistic
patterns.
Read the "Palette override presets" section in the manual for how to
use and/or extend those:
<https://protesilaos.com/emacs/modus-themes#h:b0bc811c-227e-42ec-bf67-15e1f41eb7bc>.
** Named colours are more meaningful
:PROPERTIES:
:CUSTOM_ID: h:94e59644-8ef8-4a46-9666-a241ba04b21a
:END:
In the past, the variants of the main accent colours were named like:
- =red=
- =red-alt=
- =red-alt-other=
The improved naming scheme changes those to:
- =red=
- =red-warmer=
- =red-cooler=
Semantically, the "warmer" variants have more yellow or red while the
"cooler" ones have greater contribution of cyan or blue. As such, the
user can expect =green-warmer= to be an olive green and =green-cooler=
to be that of the pine (though olive trees can have blue-green
colouration and pine trees can be "warmer", but I digress).
Named colours can be previewed with the commands
~modus-themes-list-colors~ (alias ~modus-themes-preview-colors~) and
~modus-themes-list-colors-current~ (alias
~modus-themes-preview-colors-current~).
Those commands accept a =C-u= prefix argument, in which case they show
the semantic colour mappings.
** Rationalisation of the colour palette
:PROPERTIES:
:CUSTOM_ID: h:cb378214-54a1-4b5b-a801-aa206b94ae38
:END:
In previous versions, there were a lot of named colours that were
added ad-hoc, such as =fg-special-cold= and =bg-special-calm-faint=.
There was no clear design pattern behind them, nor was it obvious
where those colours should be used. Furthermore, there were colours
that were reserved for the various permutations of user options.
This was too complex for users who wanted/needed to refashion aspects
of the themes. It was also difficult to maintain.
The new palettes are more streamlined and their application is more
predictable. This only matters to users who tweak the themes: it
makes their life easier, although it does render inapplicable any
previous custom code.
** Deprecation of user options
:PROPERTIES:
:CUSTOM_ID: h:fcaa0f80-7e78-44b1-ab04-90acb0046139
:END:
The following subsections explain the topics in further detail. The
general idea for this change is that palette overrides provide a more
powerful, more flexible, and less complex alternative. The code base
is considerably smaller.
With overrides, I can now provide support to cases such as:
- Users who need different sets of greys as their monitor has
inadequate colour reproduction (this is much more common than you
think).
- Users who want to make individual elements stand out, such as to
turn the delimiters of Org source blocks (the =#+begin_src= and
=#+end_src= lines) into, say, a shade of red.
- Users who want to tone down the =TODO= and =DONE= keywords while
making headings more colourful. Or the inverse, or any combination
in-between the extremes.
- Users who want Org property drawers to be more colourful but inline
code to be faint.
You get the idea... All these and many more are now possible.
Whereas in the past I would either have to tell people that it is not
possible or hardcode a stylistic alternative via user options, thus
further complicating the code base.
Catering to all those use-cases is important due to the maximalist
scope of the Modus themes: I cannot tell people to use another theme,
because here is where they come for their legibility needs. This is
consistent with my experience that accessibility is not a
one-size-fits-all and that the most accessible design is that which is
flexible, ceteris paribus.
*** ~modus-themes-intense-mouseovers~
:PROPERTIES:
:CUSTOM_ID: h:7f4a658a-613b-4ab9-bc05-d9aa6179830b
:END:
This user option would amplify the background colour of mouse hover
effects (technically, the ~highlight~ and ~mode-line-highlight~
faces). It always used a blue colour.
The same effect can now be achieved via overrides, except it is now
possible to use any background colour or level of intensity that is
provided by the themes' palette. The manual provides concrete
examples: <https://protesilaos.com/emacs/modus-themes#h:b5cab69d-d7cb-451c-8ff9-1f545ceb6caf>.
*** ~modus-themes-org-agenda~
:PROPERTIES:
:CUSTOM_ID: h:778abb81-4bcb-4a5c-85eb-eec9f417a443
:END:
This was a complex user option that was hard to test, document, and
maintain. Most aspects of the Org agenda can be affected via
overrides, as demonstrated in the manual:
<https://protesilaos.com/emacs/modus-themes#h:a5af0452-a50f-481d-bf60-d8143f98105f>.
*** ~modus-themes-fringes~
:PROPERTIES:
:CUSTOM_ID: h:b1ee38d7-45a0-474b-8c97-774f61462cc6
:END:
This user option provided two shades of grey and the option for an
invisible background for the Emacs fringe. The same and better can be
done via overrides, as shown in the manual:
<https://protesilaos.com/emacs/modus-themes#h:c312dcac-36b6-4a1f-b1f5-ab1c9abe27b0>.
*** ~modus-themes-lang-checkers~
:PROPERTIES:
:CUSTOM_ID: h:ad06917b-a078-48c8-97e8-1182e085a15c
:END:
This was another complex user option that offered several stylistic
variants of dubious value. The main problem it had is that linter
highlights are often applied automatically, so any super intense style
becomes unusable. Same when a file has lots of warnings/errors.
The semantic colour mappings I provide for this case are limited to
underlines, which I think is the most usable/legible design. The
manual provides concrete examples on how to tweak those:
<https://protesilaos.com/emacs/modus-themes#h:03dbd5af-6bae-475e-85a2-cec189f69598>.
*** ~modus-themes-mode-line~
:PROPERTIES:
:CUSTOM_ID: h:1b82b764-97f5-406a-8440-bae415c7d294
:END:
Yet another very complex user option that I removed in the interest of
maintainability. All its stylistic permutations (and more) for
colours are possible via overrides:
- Make the mode line borderless :: <https://protesilaos.com/emacs/modus-themes#h:80ddba52-e188-411f-8cc0-480ebd75befe>
- Make the active mode line colorful :: <https://protesilaos.com/emacs/modus-themes#h:e8d781be-eefc-4a81-ac4e-5ed156190df7>
It is also possible to add padding to the mode line, though I explain
why this was always a dirty hack:
<https://protesilaos.com/emacs/modus-themes#h:5a0c58cc-f97f-429c-be08-927b9fbb0a9c>.
*** ~modus-themes-diffs~
:PROPERTIES:
:CUSTOM_ID: h:dd2879a4-37c1-4ded-bc7e-24a217248961
:END:
I have redesigned all diff-related colours to improve their usability.
They are less intense than before, but still stand out clearly. I am
purposefully not documenting how to use overrides here as I want users
to give this redesign a try. We can always document and refine things
at a later point.
*** ~modus-themes-subtle-line-numbers~
:PROPERTIES:
:CUSTOM_ID: h:bcce1b94-a223-4324-b0a6-940e389819a8
:END:
This was a simple, but ultimately very limited option. We can do much
better with overrides because we can tweak every aspect of this
interface without making the code more complex. The manual shows how
to do it in style:
<https://protesilaos.com/emacs/modus-themes#h:b6466f51-cb58-4007-9ebe-53a27af655c7>.
*** ~modus-themes-markup~
:PROPERTIES:
:CUSTOM_ID: h:5eedfd24-9480-4b76-8b64-e625d3220a8d
:END:
This was a poorly named user option that only affected inline code
elements in prose. The new semantic colour mappings provide more
points of entry and thus make it easier to tweak things to one's
liking (including tables, property drawers, source block delimiters
(the =#+begin_src= and =#+end_src= lines)), and more. The manual
shows how:
<https://protesilaos.com/emacs/modus-themes#h:bb5b396f-5532-4d52-ab13-149ca24854f1>.
*** ~modus-themes-paren-match~
:PROPERTIES:
:CUSTOM_ID: h:8dbe54c3-5bfc-424c-8952-f68015f6c6c4
:END:
The colouration of matching parentheses of the ~show-paren-mode~ can
still be affected via overrides:
<https://protesilaos.com/emacs/modus-themes#h:259cf8f5-48ec-4b13-8a69-5d6387094468>.
*** ~modus-themes-syntax~
:PROPERTIES:
:CUSTOM_ID: h:22910131-87bf-4c03-bbf4-aac3010b570a
:END:
This was a user option that controlled the colouration of programming
modes. We can reproduce it with overrides, except we now also have
the freedom to adapt things further:
- Make comments yellow and strings green :: <https://protesilaos.com/emacs/modus-themes#h:26f53daa-0065-48dc-88ab-6a718d16cd95>
- Make code syntax use the old alt-syntax style :: <https://protesilaos.com/emacs/modus-themes#h:c8767172-bf11-4c96-81dc-e736c464fc9c>
- Make use of alternative styles for code syntax :: <https://protesilaos.com/emacs/modus-themes#h:943063da-7b27-4ba4-9afe-f8fe77652fd1>
*** ~modus-themes-links~
:PROPERTIES:
:CUSTOM_ID: h:68d41ee9-d277-45f9-a6cd-543dac9282c8
:END:
The colouration of links can now be affected via palette overrides, as
documented in the manual:
<https://protesilaos.com/emacs/modus-themes#h:6c1d1dea-5cbf-4d92-b7bb-570a7a23ffe9>.
*** ~modus-themes-region~
:PROPERTIES:
:CUSTOM_ID: h:b97b78df-9ed9-4173-8de2-303851231e06
:END:
Overrides can be used to affect the region's colouration and/or to
prevent the active region highlight from changing the underlying text
colour. As always, the manual covers the details:
<https://protesilaos.com/emacs/modus-themes#h:c8605d37-66e1-42aa-986e-d7514c3af6fe>.
*** ~modus-themes-deuteranopia~
:PROPERTIES:
:CUSTOM_ID: h:e5fee2a1-2ace-4b4b-9aea-554d2b4a7c2d
:END:
Instead of this rather limited option, users are advised to use the
new bespoke themes: ~modus-operandi-deuteranopia~ and
~modus-vivendi-deuteranopia~. They are designed to cater to the needs
of people with red-green colour deficiency.
*** ~modus-themes-mail-citations~
:PROPERTIES:
:CUSTOM_ID: h:bb8a81c5-d0c1-4150-bf7a-254d1684d95e
:END:
All parts of an email composition buffer (per the standard
=message.el= library) are configurable via palette overrides. Not
just citation lines, but also message headers. The manual shows
several stylistic alternatives:
<https://protesilaos.com/emacs/modus-themes#h:7da7a4ad-5d3a-4f11-9796-5a1abed0f0c4>.
Note that apart from this change, I also redesigned several faces that
affect emails. This was done in the interest of consistency and to
avoid some exaggerations.
*** ~modus-themes-tabs-accented~
:PROPERTIES:
:CUSTOM_ID: h:1574b5bc-d615-4053-9bbf-79396745519b
:END:
I do not provide documentation on how to reproduce this style because
I think it was not widely used. It is possible to do it with
overrides. If anyone needs it, they are invited to contact me about
it.
*** ~modus-themes-box-buttons~
:PROPERTIES:
:CUSTOM_ID: h:19c81a75-a65e-49cb-83e5-c44167821865
:END:
All "graphical" buttons use a proportionately spaced font
(~variable-pitch~) by default as it helps with legibility. The
colours of those buttons can be changed by overriding the relevant
entries:
<https://protesilaos.com/emacs/modus-themes#h:4f6b6ca3-f5bb-4830-8312-baa232305360>.
[ Use my ~fontaine~ package to affect fonts via faces and to apply
presets for various contexts. ]
** Changes to remaining user options
:PROPERTIES:
:CUSTOM_ID: h:c93db0f4-1032-411a-881e-0c5fd23480cf
:END:
*** The ~modus-themes-headings~ also affects the Org agenda
:PROPERTIES:
:CUSTOM_ID: h:c2f088b6-dc84-4285-9ece-c877be6b274f
:END:
This user option applies to heading level 0 through 8 and also to the
agenda date and structure constructs. Here is a complete example:
#+begin_src emacs-lisp
(setq modus-themes-headings ; read the manual's entry of the doc string
'((0 . (variable-pitch light 1.9))
(1 . (variable-pitch light 1.8))
(2 . (variable-pitch regular 1.7))
(3 . (variable-pitch regular 1.6))
(4 . (variable-pitch regular 1.5))
(5 . (variable-pitch 1.4)) ; absence of weight means `bold'
(6 . (variable-pitch 1.3))
(7 . (variable-pitch 1.2))
(agenda-date . (semilight 1.5))
(agenda-structure . (variable-pitch light 1.9))
(t . (variable-pitch 1.1))))
#+end_src
*** The ~modus-themes-headings~ no longer affects colours
:PROPERTIES:
:CUSTOM_ID: h:bb0bac60-ad22-4699-9579-881431972294
:END:
All colour-related changes can be done via palette overrides. This
gives the user maximum flexibility on the choice of applied colours
(e.g. to have alternating contrasting foregrounds or shades of the
same hue). The manual shows several examples:
<https://protesilaos.com/emacs/modus-themes#h:11297984-85ea-4678-abe9-a73aeab4676a>.
*** The ~modus-themes-completions~ is simpler
:PROPERTIES:
:CUSTOM_ID: h:0b29c525-7def-4149-a26b-70ca5e021a27
:END:
It no longer covers =popup= entries as distinct from =selection=.
This is because I revised all the applicable colours and faces to
consolidate styles.
The =matches= and =selection= keys now read the same list of values.
All changes to colours are done through palette overrides, as
demonstrated in the manual (again, far more flexible):
<https://protesilaos.com/emacs/modus-themes#h:d959f789-0517-4636-8780-18123f936f91>.
*** The ~modus-themes-prompts~ is simpler
:PROPERTIES:
:CUSTOM_ID: h:7e5b9fea-b696-4e8a-bebe-a7fbb0eb460a
:END:
This user option now only affects the typographic features of prompts.
It can read any font weight, as explained in its documentation.
Colours are influenced by semantic colour mappings in the palette and
can be overridden accordingly. The manual shows several styles:
<https://protesilaos.com/emacs/modus-themes#h:bd75b43a-0bf1-45e7-b8b4-20944ca8b7f8>.
*** Auto-reload theme when configuring via Custom
:PROPERTIES:
:CUSTOM_ID: h:b26a2a1f-ee1e-4001-a3d0-4d4d7cb4fd5f
:END:
The user option ~modus-themes-custom-auto-reload~ supersedes the old
~modus-themes-inhibit-reload~. It is now set to a non-~nil~ value by
default.
We do this as a convenience for users who tweak theme settings via the
Custom UI and who do not know that all modifications to user options
require a theme re-load for changes to take effect. Read more in the
manual:
<https://protesilaos.com/emacs/modus-themes#h:9001527a-4e2c-43e0-98e8-3ef72d770639>.
** Deprecation of public functions
:PROPERTIES:
:CUSTOM_ID: h:8167bf46-7a43-4b46-b2ed-a66e5d73bb96
:END:
The ~modus-themes-color~ and ~modus-themes-color-alts~ are deprecated.
Users are invited to concentrate on the ~modus-themes-with-colors~
macro. The manual provides several examples on that front.
The ~modus-themes-load-themes~ is no longer necessary due to the
refactoring of the code base.
The ~modus-themes-load-operandi~ and ~modus-themes-load-vivendi~ are
superseded by the general ~modus-themes-load-theme~. It accepts the
symbol of a Modus theme as its argument.
The command ~modus-themes-report-bug~ is no more. Just send an email
to the mailing list or to me privately. Find the information with
=M-x describe-package= and then specify =modus-themes=.
Alternatively, check my website: <https://protesilaos.com/contact>.
** Removed support for some packages
:PROPERTIES:
:CUSTOM_ID: h:34ffc5ed-574d-44f1-8a27-c2e6bb8c69e0
:END:
These are the most notable packages that are no longer supported:
- ~dired+~
- ~lsp-mode~
- ~helm~
- ~treemacs~
The reason is that they are very hard to use for me as an outsider.
They provide lots of features, which means that I cannot easily
identify faces in their context unless I become an expert in the
relevant functionality.
Other removed packages:
- ~artbollocks-mode~. Use ~writegood-mode~.
- ~apropos~. Its default faces are fine.
- ~awesome-tray~.
- ~bbdb~ and ~ebdb~. They are hard to set up, but their faces are
usable.
- ~calfw~. Hard to set up and also seems to no longer be maintained.
- ~easy-jekyll~
- ~dir-treeview~
- ~eros~
- ~eshell-git-prompt~
- ~eshell-prompt-extras~
- ~eshell-syntax-highlighting~
- ~evil-goggles~
- ~evil-snipe~
- ~evil-visual-mark-mode~
- ~fountain-mode~. I need someone who uses it to help me test it.
- ~macrostep~
- ~mentor~
- ~mini-modeline~
- ~mmm-mode~. I need someone who uses it to help me test it.
- ~org-table-sticky-header~.
- ~phi-grep~
- ~pomidor~
- ~rainbow-blocks~. Use Adam Porter's (aka alphapapa) =prism.el=.
- ~semantic~
- ~smartparens~
- ~spaceline~
- ~sx~
- ~telephone-line~
- ~tomatinho~
- ~winum~
- ~xterm-color~.
** Thanks for their feedback on the development of version 4
:PROPERTIES:
:CUSTOM_ID: h:bdaa3eaf-67e8-4de8-b8d5-7b11fa28dbcd
:END:
In alphabetical order:
- Aleksei Pirogov :: Noticed that there were no semantic colour
mappings for the ~rainbow-delimiters~ (and related), thus reminding
me to make the requisite arrangements. Aleksei also spotted a
regression during the development of the "faint" overrides' preset.
These were done on the GitHub mirror:
- <https://github.com/protesilaos/modus-themes/issues/54>
- <https://github.com/protesilaos/modus-themes/issues/55>
- Anders Johansson :: Pointed out some irregularities with the use of
~make-obsolete~ in the =version-4= development branch. I should be
using ~make-obsolete-variable~ in some cases:
<https://lists.sr.ht/~protesilaos/modus-themes/%3CCAKJdtO-dzvR%3D2BaSd5qPzwDE%3D%2BaJSR6js7ii1O6KD7oFOB7gDw%40mail.gmail.com%3E>
- Charlotte Van Petegem :: Reminded me to document how to reproduce
the old "alt-syntax" style by using palette overrides:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C877cy917jw.fsf%40vanpetegem.me%3E>
- Christian Tietze :: Spotted a bug in how shared palette overrides
would not be read in certain scenaria. Also suggested tweaks to the
documentation, which reminded me of tasks that still had to be done:
- <https://lists.sr.ht/~protesilaos/modus-themes/%3Cm1cz81rq9m.fsf%40christiantietze.de%3E>
- <https://lists.sr.ht/~protesilaos/modus-themes/%3Cm1fscxrr0s.fsf%40christiantietze.de%3E>
- <https://lists.sr.ht/~protesilaos/modus-themes/%3Cm1ilhtrs09.fsf%40christiantietze.de%3E>
- Daniel Mendler (aka @minad on GitHub) :: Contacted me to comment on
the general redesign. From the discussion I learnt that preset
overrides would be useful. This information is shared with
permission, as it was done via a private channel.
- James Ferguson :: Commented on the colours of the tab-bar and thus
inspired me to define relevant semantic colour mappings:
<https://lists.sr.ht/~protesilaos/modus-themes/%3CCAMtGdSnrKDGdagT7vGC9DnBZnOvkbM%3D4Nxwn3ts2tdO8YmUnxw%40mail.gmail.com%3E>
- Philip Kaludercic :: Opined that the ~modus-themes-inhibit-reload~
should not be deprecated in the interest of usability. As noted
above, its functionality is preserved and now enabled by default in ~modus-themes-custom-auto-reload~. Through the discussion we also
arrived at the concept of shared palette overrides instead of only
having theme-specific ones:
- <https://lists.sr.ht/~protesilaos/modus-themes/%3C87h6y3gyxx.fsf%40posteo.net%3E>
- <https://lists.sr.ht/~protesilaos/modus-themes/%3C87wn6qgjkx.fsf%40posteo.net%3E>
- Tony Zorman :: Noted that there was no clear upgrade path to
version 4. This helped me explain some of the technicalities of
packaging and of the themes' redesign, but also to update the
manual:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C874jtew0gp.fsf%40hyperspace%3E>.
- a1ks :: Reported a bug caused by the typo of an extra backtick.
This was done on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/53>.
- soaringbind :: Identified some omissions in the code where I forgot
to update certain Avy and Org faces. This continued in a second
thread about the use of some obsolete faces:
- <https://lists.sr.ht/~protesilaos/modus-themes/%3CNKXY2k1--3-9%40tuta.io%3E>
- <https://lists.sr.ht/~protesilaos/modus-themes/%3CNKd3jM_--3-9%40tuta.io%3E>
- tumashu :: Experimented with the overrides and thus helped me
identify an area where the documentation could be improved. This
was done on the GitHub mirror:
- <https://github.com/protesilaos/modus-themes/issues/56>
- <https://github.com/protesilaos/modus-themes/issues/57>
- wakamenod :: Encountered a bug that was caused by a mistake of mine
that affected how themes are instantiated. This was done on the
GitHub mirror: <https://github.com/protesilaos/modus-themes/issues/50>.
** The largest release to date
:PROPERTIES:
:CUSTOM_ID: h:54a6bcd1-6ba0-42ed-8fdd-b83ee3efee73
:END:
There are many more changes that I did not describe. This already
lengthy document is me covering just the headline features. The gist
is that I spent the last month refactoring and testing the themes to
ensure they can cope with the needs of users for years to come.
I understand that the palette overrides are a new way of doing things
and that some users may be inconvenienced over the short-term as they
update their configurations. I strongly believe that this system is
better and the Modus themes can now cover all the legibility needs of
users, while also catering to their aesthetic preferences.
+ Package name (GNU ELPA): ~modus-themes~
+ Official manual: <https://protesilaos.com/emacs/modus-themes>
+ Change log: <https://protesilaos.com/emacs/modus-themes-changelog>
+ Colour palette: <https://protesilaos.com/emacs/modus-themes-colors>
+ Sample pictures: <https://protesilaos.com/emacs/modus-themes-pictures>
+ Git repo on SourceHut: <https://git.sr.ht/~protesilaos/modus-themes>
- Mirrors: + GitHub: <https://github.com/protesilaos/modus-themes>
+ GitLab: <https://gitlab.com/protesilaos/modus-themes>
+ Mailing list: <https://lists.sr.ht/~protesilaos/modus-themes>
+ Backronym: My Old Display Unexpectedly Sharpened ... themes
* 3.0.0
:PROPERTIES:
:CUSTOM_ID: h:6829db8d-52c5-43a8-a026-f213dcfaced9
:END:
#+begin_src text
Modus themes version 3.0.0
By Protesilaos Stavrou <info@protesilaos.com> on 2022-10-28
The version that will ship with Emacs 29
========================================
The 'modus-operandi' and 'modus-vivendi' themes (package name is
'modus-themes') have been a part of Emacs since August 2020. Emacs 28
ships with version 1.6.0 of the themes. Emacs 29 will include version
3.0.0.
There is no clean upgrade path from the old version of the themes to
the current one. Users are advised to review their configurations and
consult with the detailed manual of the themes.
I am available to answer any questions, either via my personal email
or on the official sources of the themes. Find the full list here:
<https://protesilaos.com/emacs>.
Minor breaking changes
======================
I have changed the default value of the following user options:
1. 'modus-themes-hl-line'
2. 'modus-themes-completions'
3. 'modus-themes-fringes'
In the case of the first two, the background of the highlighted line
is made to look a bit more intense.
For the fringes, this tweak makes them visible, using a subtle grey
colour. By default, "fringe" is an 8-pixel-wide area to the left and
right side of an Emacs window.
The intent of these changes is to make the out-of-the-box experience
consistent with the accessibility considerations of the Modus themes.
Specifically because some users may not realise that the themes are
highly customisable.
To revert to the old defaults, users must include this (or equivalent)
in their init file:
(setq modus-themes-completions nil
modus-themes-hl-line nil
modus-themes-fringes nil)
As always, changes to theme user options take effect upon a reload of
the theme.
This was announced on my website:
<https://protesilaos.com/codelog/2022-10-23-breaking-modus-themes-3-0-0-notice/>.
Support for new faces or changes to existing ones
=================================================
,* Refined the 'telega' faces for inline code and preformatted
elements. The faces are 'telega-entity-type-code' and
'telega-entity-type-pre', respectively. This change makes them
subject to the style specified in the user option
'modus-themes-markup'.
Thanks to Pablo Stafforini for showing me screenshots of how they
look, as I am not a telega/telegram user and cannot do this myself.
Done as part of issue 170 on the GitLab mirror:
<https://gitlab.com/protesilaos/modus-themes/-/issues/170#note_1143975582>.
,* Removed all attributes from the 'textsec-suspicious' face. By
default, it applies a background, but does not affect the
foreground. The result is thus inaccessible in many cases
(e.g. blue links against a red background). There is no need for
such a background though, as the warnings are accompanied by the
relevant emoji: ⚠️.
To support this face, we need it to affect the foreground as well.
,* Deleted some 'consult' "preview" faces in the interest of
consistency. This is to match the current style of the project:
<https://github.com/minad/consult/commit/1343e39fefcf8a28a7a415aa4b0a8ff7094370bf>.
,* Expanded support of the built-in 'diff-mode' faces to include the
'diff-changed-unspecified'. It is made to look the same as
'diff-changed', i.e. yellow-tinted. There is a good chance that a
user will never see this face in action (I only encountered it
once).
,* Reworked all the 'highlight-regexp' faces (like 'hi-yellow') to use
bespoke colour values.
These faces need to have a background that is consistent with their
semantics. Furthermore, they need to use the 'inverse-video'
attribute which, in turn, affects the combinations of colour we can
apply. Our accented backgrounds are designed to contrast well with
our nominal main foreground values, whereas this case demands
coloured backgrounds that contrast nicely with what would normally
be the main background colour. As such, we cannot apply our
ordinary entries from each theme's palette. It would be inefficient
to expand the palette of each theme just for this edge case.
Thanks to Kevin Kainan Li for the feedback on the mailing list, where
they informed me that the previous design was too dark/mute (and I
agreed with that assessment) and provided feedback on my samples:
<https://lists.sr.ht/~protesilaos/modus-themes/%3CCAMTq2Vp3Nnzv-i9wJdq4-OJ4X_QfWXySpUtAieBy0dgKLEOSBg%40mail.gmail.com%3E>.
,* Recoloured the 'modus-themes-completion-match-1' to use a shade of
blue instead of cyan. This contributes to the distinctiveness of
those matches relative to 'modus-themes-completion-match-0' and the
other groups. These faces are used in completion User Interfaces,
such as 'vertico', 'corfu', 'orderless'. They are subject to the
user option 'modus-themes-completions'.
,* Added support for the 'olivetti-fringe' face. Its background is the
same as the main background, meaning that the fringes are invisible
when 'olivetti-mode' is enabled. Thanks to Matthias Fuchs for
producing a report that helped me track this problem. It was done
in issue 46 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/46>.
Miscellaneous
=============
,* Added the new Emacs 29 theme properties to 'modus-operandi' and
'modus-vivendi'. These make the themes work with the new built-in
command 'toggle-theme'. Thanks to Philip Kaludercic for the patch
and for the work on this in emacs.git:
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg00886.html>.
,* Refrained from deprecating the 'modus-themes-toggle' command in
favour of the new generic 'toggle-theme'.
The 'toggle-theme' is not functionally equivalent to the command
'modus-themes-toggle' due to the optional arguments it accepts.
With 'toggle-theme' we are prompted to confirm loading the theme,
due to how unsafe themes can be... Further, we are asked to add the
loaded theme to the list of "safe" themes. This only applies to the
packaged version of the 'modus-themes', not the items that are built
into Emacs.
These prompts are consistent with how 'load-theme' works, but not
with what the user of 'modus-themes-toggle' has come to expect.
Users who do not like to maintain a 'custom-file' (like me) are thus
penalised each time they invoke the command.
The 'modus-themes-toggle' will only be deprecated if there is, say,
a user option in Emacs that disables those prompts each time a theme
is loaded. Basically, we need an arrangement that just toggles
themes without questions.
Thanks to Rudolf Adamkovič for suggesting the idea and to Philip
Kaludercic for the 'toggle-theme' (and related functionality):
<https://lists.sr.ht/~protesilaos/modus-themes/%3C877d116lh4.fsf%40posteo.net%3E#%3Cm2lepgrd8l.fsf@me.com%3E>.
,* Corrected the one-line description of the 'modus-vivendi' theme,
which was describing itself as a "light" theme.
,* Ensured that the manual and all doc strings in the code use American
English, per the convention of emacs.git (my CHANGELOG still uses
what I prefer). Thanks to Stefan Kangas for contributing to this
effort with a patch that properly renders 'non-nil' in the texinfo
output as 'non-@code{nil}'.
,* Made other minor tweaks and refinements.
#+end_src
* 2.7.0
:PROPERTIES:
:CUSTOM_ID: h:4d86106c-1df5-4f5f-bc6c-f14f5d13403b
:END:
#+begin_src text
Modus themes version 2.7.0
By Protesilaos Stavrou <info@protesilaos.com> on 2022-10-01
Support for packages or faces
=============================
,* Reinstated support for 'centaur-tabs'. I had removed it in commit
2235ce5 (done on 2022-08-02) for version 2.5.0 of the modus-themes.
At the time I wrote:
centaur-tabs has a bug where it cannot read the value of a face if it
uses the standard ':inherit' attribute. I have sent a patch to fix it,
but have received no response since February:
<https://github.com/ema2159/centaur-tabs/pull/179>.
Relevant reports:
- <https://github.com/protesilaos/modus-themes/issues/30>
- <https://gitlab.com/protesilaos/modus-themes/-/issues/288>
- <https://github.com/protesilaos/modus-themes/issues/15>
I am happy to reinstate support for centaur-tabs as soon as the package
gets the maintenance it needs.
My patch/pull-request is now merged and the package is actively
maintained once again. Hence the decision to bring back support for
it, as promised.
,* Applied styles for the 'icon-button' face of Emacs 29.
,* Styled the 'log-edit-headers-separator' face of Emacs 29 (it was
introduced upstream by a patch of mine).
,* Made the 'gnus-summary-low-unread' face inherit from the 'italic'
face like the rest of that subgroup of faces. This helps
differentiate it from the 'gnus-summary-high-unread' face. Thanks
to Mark Simpson for pointing out the possibility of conflating those
two faces: <https://lists.sr.ht/~protesilaos/modus-themes/%3Cm2r0zszc2z.fsf@gmail.com%3E>.
,* Covered the 'read-multiple-choice-face' by adding a noticeable
background colour to it. The default attributes it has, which look
like other key bindings (bold and blue) plus an underline are
technically okay, though the context of this face is in the echo
area which is one line tall. Moreover, the highlighted keys are
inlined with other text. These make it difficult to spot the
highlights without some extra spacing. I use the addition of a
background in Org's export dispatcher interface which also has some
unique requirements (the 'org-dispatcher-highlight' face). The
principle is to have theme-wide consistency (e.g. "all key bindings
must look the same") EXCEPT when the specifics require a different
set of styles in the interest of usability.
,* Extended the coverage of the 'auctex' package's faces to include the
'font-latex-underline-face'. Thanks to Luis Miguel Castañeda for
reporting a typo I made which caused an error:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C7h7d2oudpb.fsf@imaginarymagnitude.net%3E>
,* Added support for 'crontab-mode'. Thanks to Antonio Ruiz for the
patch: <https://lists.sr.ht/~protesilaos/modus-themes/patches/35080>. It
is below the ~15 line threshold and thus requires no copyright
assignment to the Free Software Foundation.
,* Extended support for the 'company' package's 'company-scrollbar-bg'
and 'company-scrollbar-fg' faces.
,* Added support for the 'spell-fu' package. Thanks to Antonio Ruiz
for the patch: <https://lists.sr.ht/~protesilaos/modus-themes/%3C87fshnq7uv.fsf%40purelymail.com%3E>.
Same as further above for Antonio's copyright status.
,* Moved the 'selectrum-prescient' faces to the 'prescient' group, to
be consistent with changes in the respective upstream packages.
Thanks to okamsn for the contribution, which was done in pull
request 41 on the GitHub mirror: <https://github.com/protesilaos/modus-themes/pull/41>.
The user okamsn has assigned copyright assignment to the Free
Software Foundation, although this patch is within the allowed
limits.
Change to 'fill-column-indicator'
=================================
Made the 'fill-column-indicator' face more noticeable. It is what the
'display-fill-column-indicator-mode' uses to draw a line on where the
'fill-column' is.
This change is in response to private messages I received as well as
this, at parts impolite and toxic, thread that I refrained from
participating in:
<https://lists.gnu.org/archive/html/help-gnu-emacs/2022-08/msg00255.html>.
[ I do not follow that mailing list, by the way. All my projects have
multiple communication channels and I always reply in a timely
fashion. Social media, fora about Emacs, generic mailing lists,
etc. are not among those channels.
<https://protesilaos.com/codelog/2022-07-24-report-issues-official-channels/>. ]
The core idea is that the previous design was (1) considered
"invisible" and (2) it prevented the customisation of the user option
'display-fill-column-indicator-character'.
I am addressing point 1, but point 2 puts us in an awkward spot as we
would then not be allowed to use a background and a height value. Not
doing so produces a dashed line by default, with the dashes further
apart the greater the line-spacing is (especially in, say, Org
headings that can have a greater height than paragraph text). It
looks broken and I keep getting requests to fix what is not the
themes' fault. So no, the themes will remain opinionated in this
regard by ignoring 'display-fill-column-indicator-character' through
the styling they apply to make the line contiguous.
For context, also read Emacs bug#57424 and please don't take my words
in a private message out of context. If I need to state my opinion in
a public setting, I know how to do it.
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57424>.
Refinement to modus-vivendi 'bg-diff-focus-removed' colour
==========================================================
Made the default removed diff background slightly more luminant. The
colour is seen in diff-mode, ediff, and the Magit focused diff hunk.
When the user option 'modus-themes-diffs' is set to either 'bg-only' or
'desaturated', this colour is used to highlight word-wise ("refined")
changes. The increased luminance lets it stand out more compared to the
more subtle backdrop.
Thanks to Kévin Le Gouguec for bringing this issue to my attention and
for discussing it with me:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87bks4i9tg.fsf@gmail.com%3E>
Note about 'goto-address-mode'
==============================
Quote from the manual:
The built-in 'goto-address-mode' uses heuristics to identify URLs and
email addresses in the current buffer. It then applies a face to them
to change their style. Some packages, such as 'notmuch', use this
minor-mode automatically.
The faces are not declared with 'defface', meaning that it is better
that the theme does not modify them. The user is thus encouraged to
consider including (or equivalent) this in their setup:
(setq goto-address-url-face 'link
goto-address-url-mouse-face 'highlight
goto-address-mail-face 'link
goto-address-mail-mouse-face 'highlight)
My personal preference is to set 'goto-address-mail-face' to nil, as
it otherwise adds too much visual noise to the buffer (email addresses
stand out more, due to the use of the uncommon '@' character but also
because they are often enclosed in angled brackets).
Changes to the manual
=====================
,* Fixed a few typos and ensured that spelling using American English
as that is what emacs.git requires.
,* Added the missing ':config' keywords from the example configuration
of the 'circadian' package. Thanks to Koen van Greevenbroek for the
patch: <https://lists.sr.ht/~protesilaos/modus-themes/%3C8735cb6zm3.fsf%40posteo.net%3E>.
#+end_src
* 2.6.0
:PROPERTIES:
:CUSTOM_ID: h:fc108f65-3e0b-4e28-8030-86c797cb2b25
:END:
#+begin_src text
Modus themes version 2.6.0
By Protesilaos Stavrou <info@protesilaos.com> on 2022-08-19
Changes to supported faces or face groups
=========================================
,* Made the 'font-lock-warning-face' adapt to comments. This changes the
face from a yellow to a red hue when the user adds a value to
'modus-themes-syntax' which includes 'yellow-comments' property.
Before, this face was indistinguishable from yellow comments due to a
regression in version 2.5.0 of the themes. Thanks to Augusto Stoffel
and Manuel Uberti for their feedback on the mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87r11k1c22.fsf%40gmail.com%3E>.
,* Applied a consistent foreground color (a not-so-intense yellow hue) to
the 'org-checkbox' and 'markdown-gfm-checkbox-face'. The change comes
from the discussion on the mailing list where it became apparent that
a bit of colour is needed for such constructs:
<https://lists.sr.ht/~protesilaos/modus-themes/%3Cm2fsi9cja4.fsf%40me.com%3E>.
Thanks to Rudolf Adamkovič, Christian Tietze, and Karthik Chikmagalur
for their participation.
,* Added support for the 'mu4e-related-face'. Thanks to Simon Pugnet for
the feedback on the mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87edxhvqwp.fsf@polaris64.net%3E>.
,* Included support for the 'consult-preview-insertion' face. There are
two reasons for adding this:
1. It decouples it from the 'region' face, which means that the user
option 'modus-themes-region' no longer has an unintended effect on
it.
2. It makes it look consistent with the 'rectangle-preview' face (see
it in action with C-x SPC, move point down a few lines, type C-t
and then insert some text). I feel these sort of previews need to
look the same, though I don't have a strong attachment to the style
now in use.
Removed support for the 'solaire' package
=========================================
The 'solaire-mode' package dims the background of what it considers
ancillary "UI" buffers, such as the minibuffer and Dired buffers. The
Modus themes used to support Solaire on the premise that the user was
(i) opting in to it, (ii) understood why certain buffers were more gray,
and (iii) knew what other adjustments had to be made to prevent broken
visuals (e.g. the default style of the 'modus-themes-completions' uses a
subtle gray background for the selection, which with Solaire becomes
practically invisible).
However, the assumption that users opt in to this feature does not
always hold true. There are cases where it is enabled by default such
as in the popular Doom Emacs configuration. Thus, the unsuspecting user
who loads 'modus-operandi' or 'modus-vivendi' without the requisite
customizations is getting a sub-par experience; an experience that we
did not intend and cannot genuinely fix.
[ Relevant reading about "The case of git-gutter, the modus-themes, and
Doom Emacs":
<https://protesilaos.com/codelog/2022-08-04-doom-git-gutter-modus-themes/> ]
Because the Modus themes are meant to work everywhere, we cannot make an
exception for Doom Emacs and/or Solaire users. Furthermore, we shall
not introduce hacks, such as by adding a check in all relevant faces to
be adjusted based on Solaire or whatever other package. Hacks of this
sort are unsustainable and penalize the entire userbase. Besides, the
themes are built into Emacs and we must keep their standard high.
The fundamental constraint with Solaire is that Emacs does not have a
real distinction between "content" and "UI" buffers. For themes to work
with Solaire, they need to be designed around that package. Such is an
arrangement that compromises on our accessibility standards and/or
hinders our efforts to provide the best possible experience while using
the Modus themes.
As such, 'solaire-mode' is not---and will not be---supported by the
Modus themes (or any other of my themes, for that matter). Users who
want it must style the faces manually. Below is some sample code, based
on what we cover at length in the manual:
(defun my-modus-themes-custom-faces ()
(modus-themes-with-colors
(custom-set-faces
`(solaire-default-face ((,class :inherit default :background ,bg-alt :foreground ,fg-dim)))
`(solaire-line-number-face ((,class :inherit solaire-default-face :foreground ,fg-unfocused)))
`(solaire-hl-line-face ((,class :background ,bg-active)))
`(solaire-org-hide-face ((,class :background ,bg-alt :foreground ,bg-alt))))))
(add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-custom-faces)
Changes to the manual
=====================
,* Added a missing parenthesis to a sample code block. Thanks to Paul
David for the contribution in pull request 39 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/pull/39>.
,* Clarified the wording of individual statements pertaining to the need
of reloading a theme for changes to user options to become effective.
#+end_src
* 2.5.0
:PROPERTIES:
:CUSTOM_ID: h:32438044-6eee-4909-8e5a-860ce1457049
:END:
#+begin_src text
Modus themes version 2.5.0
By Protesilaos Stavrou <info@protesilaos.com> on 2022-08-03
This entry documents the changes made to the project since the
publication of version 2.4.0 on 2022-06-01. It spans more than 60
commits to an already stable project.
The 'modus-operandi' and 'modus-vivendi' themes are built into Emacs-28
(latest 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 packaged version is available as
'modus-themes'.
Read the manual inside Emacs by evaluating:
(info "(modus-themes) Top")
Or visit: <https://protesilaos.com/emacs/modus-themes> (the website only
documents the latest version).
Enhancement to the user option 'modus-themes-headings'
======================================================
The user option 'modus-themes-headings' now reads a level 0 heading in
addition to numbers 1--8. Heading 0 accepts the same list of properties
as all other levels (please consult the doc string of the user option or
the corresponding entry in the manual). Currently only the value of the
Org #+title is affected (face is 'org-document-title'), but we may cover
more faces if needed.
Sample configuration:
;; The `modus-themes-headings' is an alist with lots of possible
;; combinations, including per-heading-level tweaks: read the
;; manual or its doc string.
(setq modus-themes-headings
'((0 . (variable-pitch light (height 2.2)))
(1 . (rainbow variable-pitch light (height 1.6)))
(2 . (rainbow variable-pitch light (height 1.4)))
(3 . (rainbow variable-pitch regular (height 1.3)))
(4 . (rainbow regular (height 1.2)))
(5 . (rainbow (height 1.1)))
(t . (variable-pitch extrabold)))
Given this change, I am also tweaking the default foreground value of
the 'org-document-title'. It is a bit more saturated than before, but
remains close to the spirit of the previous one.
Thanks to Rudolf Adamkovič for proposing the idea on the mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3Cm2y1x5tewl.fsf@me.com%3E>.
Stylistic tweak to the user option 'modus-themes-syntax'
========================================================
Prevented the 'alt-syntax' property from desaturating the effect of the
'yellow-comments' property when the two would be combined. Such as:
(setq modus-themes-syntax '(alt-syntax yellow-comments))
The previous design was incorrect because it was always using the faint
variant of the yellow comments, as if the user had specified:
(setq modus-themes-syntax '(alt-syntax faint yellow-comments))
[ Read the doc string of 'modus-themes-syntax' or the manual for an
explanation of all properties and their combinations. ]
Review of the Isearch (and related) colours
===========================================
Emacs' standard search has a face for the currently matched query and
all its inactive matches. The faces are 'isearch' and 'lazy-highlight',
respectively. Before, we were using a green background by default for
the 'isearch' face and a cyan background for the 'lazy-highlight'. This
was a choice that was made in the early days of the project when the
palette was not yet fully realised.
Green and cyan do not always contrast well side-by-side (subject to
hardware capabilities and environmental lighting), so the 'isearch' face
also had an added bold weight. This was not my preference, but it was
necessary under the circumstances. The previous combinations were also
not ideal when the user option 'modus-themes-deuteranopia' was set to a
non-nil value: the blue background which was used instead of the green
one could be conflated with the subtle teal of the 'lazy-highlight'
under certain circumstances, such as poor colour reproduction at the
monitor level or in terminal emulators with limited colour support.
The new colours (intense yellow for active matches and subtle cyan for
lazy ones) are complementary, meaning that they are naturally easy to
tell apart.
[ Read "Colour theory and techniques used in the Modus themes":
<https://protesilaos.com/codelog/2022-04-21-modus-themes-colour-theory/> ]
These specific hues are also well-suited for users with red-green colour
deficiency: yellow stays as-is, while the cyan colour becomes a bit more
grey though remains distinct. As such, we do not need to run the helper
function 'modus-themes--deuteran' to set the style based on the value of
'modus-themes-deuteranopia'.
The new colours do not clash with the style of the relevant 'match' face
(used by 'M-x occur', 'M-x grep', and related), nor with the various
permutations of the 'region' face (subject to the user option
'modus-themes-region').
Finally, the bold weight has been removed from the 'isearch' face. It
was always a kludge. Also, it would make paragraphs rendered in the
'variable-pitch' face (or proportional fonts in general) jump around as
the user would move between the matches, because bold letters occupy
more space than their regular weight counterparts so they affect the
length of the line. This problem was reported by Augusto Stoffel on the
mailing list: <https://lists.sr.ht/~protesilaos/modus-themes/%3C87sfnbswe9.fsf@gmail.com%3E>.
Rewrote parts of the colour preview commands
============================================
The 'modus-themes-list-colors', 'modus-themes-list-colors-current' are
commands that produce a buffer which shows previews of every entry in
the palette. Their code has been simplified and they now produce a
warning when the display terminal has limited colour support.
Furthermore, they read any overrides as specified in the user options
'modus-themes-operandi-color-overrides', 'modus-themes-vivendi-color-overrides'.
The "summertime" re-spin of colour overrides
============================================
The manual now includes a complete hand-crafted example of a pair of
themes that override the default palette. This is done as a technology
demonstration. It is not considered an "official" extension of the
Modus themes and will never be part of the code base as it does not
conform with our lofty accessibility standards. However, I took great
care in picking the colour overrides in the hope that users will (i)
have a usable theme, should they opt for it, and (ii) they recognise the
potential of our colour-overriding feature.
Screenshots and related information:
<https://protesilaos.com/codelog/2022-07-26-modus-themes-color-override-demo/>.
Thanks to user “Summer Emacs” for (i) suggesting the name “summertime”,
(ii) testing variants of this in her setup, and (iii) sending me
feedback on possible tweaks and refinements. All errors are my own.
The idea for this project came from an exchange where Summer discovered
an old theme of mine (from my pre-Emacs days) and asked if I had
anything like it for Emacs. Voilà!
[ This information is shared with permission. ]
As for whether I have more plans... "Perhaps!" ;)
Removed support for certain packages or face groups
===================================================
I periodically install and use the packages we support to see if they
have any updates we need to cover but also to confirm that they work.
Usually, the user does not learn about this work, as I don't need to
make any changes or will make some minor tweaks. When I think that the
package is not in a good shape, I remove it from the list of explicitly
supported packages, meaning that the modus-themes no longer cover the
faces it defines. The removal of any package is done on a case-by-case
basis. If you disagree with this decision, please inform me about and I
shall reconsider.
,* centaur-tabs :: Those of you who have been reading these release notes
are aware of a bug in centaur-tabs which basically prevents us from
using the standard ':inherit' attribute to style the centaur-tabs
faces. I have sent a patch to fix it, but have received no response
since February: <https://github.com/ema2159/centaur-tabs/pull/179>.
To me, this gives the package the "unmaintained" status, though I am
happy to revert the change as soon as it gets the maintenance it
needs.
Relevant reports (and I got many others in my private inbox):
- <https://github.com/protesilaos/modus-themes/issues/30>
- <https://gitlab.com/protesilaos/modus-themes/-/issues/288>
- <https://github.com/protesilaos/modus-themes/issues/15>
,* cursor-flash :: its default face should be visible enough.
,* dynamic-ruler :: The package does not build on my Emacs 29. Also, its
default faces are usable even without our recolouring.
,* emacs-dashboard :: Its default faces inherit from basic faces that we
already support.
,* frog-menu :: I have not seen this package being used anywhere. I
suspect it is because it has not found a niche between transient,
hydra, and embark.
,* mct :: A few months ago I announced that its development is
discontinued. Either use vertico or switch to what Emacs provides as
a built-in option: <https://protesilaos.com/codelog/2022-04-14-emacs-discontinue-mct/>.
,* org-treescope :: The package points to a GitHub repo, which is
archived. The current source is on GitLab, but the package is not
updated accordingly. This makes me believe it is not actively
maintained and am thus removing it from the list.
,* paradox :: When I tried paradox, it took over my C-c g binding which I
have for Magit. As an Emacs user, I consider this an unacceptable
transgression. Looking at paradox's git repo, the project is not
maintained. If things change, I am happy to reinstate support for it.
,* vc-annotate (built-in) :: It has not been working properly for a long
time now. Colours are unset and are not re-applied when switching
between the 'modus-operandi' and 'modus-vivendi' themes.
Furthermore, the way 'vc-annotate-color-map' intersects with
'vc-annotate-background-mode' puts us in an awkward spot: when the
mode is non-nil, the mapped values are used as backgrounds WITHOUT
giving us the chance to make the appropriate adjustments to the
foreground (so we end up with inaccessible colour combinations). This
means that we must fix a problem which is not ours by overriding the
user option of the background altogether. A theme outright disabling
user options is bad form.
Even documenting a user-level set of configurations will not suffice,
as the results are unreliable. I tried the code which I copy further
below to test annotation with/without background, plus the change in
values when switching between modus-operandi and modus-vivendi.
Again, colours are not updated properly (I know the buffer of 'M-x
vc-annotate' needs to be generated again), as 'modus-operandi' may
retain the values set by 'modus-vivendi' or vice-versa.
Ultimately, I feel 'vc-annotate' needs to be refactored to use
ordinary faces in ordinary ways. Or, at least, not try to outsmart
the user/theme about the choice of colours.
Thanks to Philip Kaludercic for starting the thread about the
'vc-annotate-background-mode' which reminded me about this problem:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C875ylfxkgi.fsf@posteo.net%3E>.
The code I alluded to:
(setq vc-annotate-background-mode nil)
(defun my-modus-themes-vc-annotate ()
;; Actual values are for demo purposes
(modus-themes-with-colors
(if vc-annotate-background-mode
(setq vc-annotate-background bg-alt
vc-annotate-color-map
`((20 . ,red-intense-bg)
(40 . ,red-subtle-bg)
(60 . ,red-refine-bg)
(80 . ,yellow-intense-bg)
(100 . ,yellow-subtle-bg)
(120 . ,yellow-refine-bg)
(140 . ,magenta-intense-bg)
(160 . ,magenta-subtle-bg)
(180 . ,magenta-refine-bg)
(200 . ,cyan-intense-bg)
(220 . ,cyan-subtle-bg)
(240 . ,cyan-refine-bg)
(260 . ,green-intense-bg)
(280 . ,green-subtle-bg)
(300 . ,green-refine-bg)
(320 . ,blue-intense-bg)
(340 . ,blue-subtle-bg)
(360 . ,blue-refine-bg)))
(setq vc-annotate-background nil
vc-annotate-color-map
`((20 . ,red)
(40 . ,magenta)
(60 . ,magenta-alt)
(80 . ,red-alt)
(100 . ,yellow)
(120 . ,yellow-alt)
(140 . ,fg-special-warm)
(160 . ,fg-special-mild)
(180 . ,green)
(200 . ,green-alt)
(220 . ,cyan-alt-other)
(240 . ,cyan-alt)
(260 . ,cyan)
(280 . ,fg-special-cold)
(300 . ,blue)
(320 . ,blue-alt)
(340 . ,blue-alt-other)
(360 . ,magenta-alt-other))))))
(add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-vc-annotate)
Revised supported faces or face groups
======================================
,* Enhanced the default background colour of the current date in the Org
agenda. This is a subtle change, all things considered, which makes
it easier to discern where the highlight is while it remains close to
the spirit of the previous design. The idea is to not add too much
saturation here, because the buffer is already "busy" with lots of
highlights. Thanks to Daniel Mendler for the feedback on the mailing
list: <https://lists.sr.ht/~protesilaos/modus-themes/%3C3d8b1096-a7db-1e08-fefe-d39bed4a7ea3@daniel-mendler.de%3E>.
,* Restyled the 'M-x man' and 'M-x woman' faces to have a bit more
saturation. A while ago I desaturated the 'Man-overstrike' and
'woman-bold' faces on the premise that the added bold weight would be
sufficient. However, the bold weight may sometimes not draw the
desired attention, such as at small point sizes or with certain font
configurations. As such, the added intensity in colour is necessary.
,* Changed the Selectrum quick key faces ('selectrum-quick-keys-match'
and 'selectrum-quick-keys-highlight') to have the same style as Avy,
Vertico's own "quick keys", and related. For a technical analysis,
read "Modus themes: case study on Avy faces and colour combinations":
<https://protesilaos.com/codelog/2022-04-20-modus-themes-case-study-avy/>.
,* Made internal adjustments so that 'M-x list-packages' inherits from
the standard 'success', 'warning', and 'error' faces instead of adding
its own face attributes. In practice, the user will notice a change
for new packages in the listing if 'modus-themes-deuteranopia' is
non-nil.
,* Introduced the same inheritance rules as above for the 'syslog'
package (mutatis mutandis).
,* Increased the saturation of the 'package-status-available' face, which
is shown in the 'M-x list-packages' buffer. The overall effect is
subtle, though sufficiently noticeable.
,* Revised the faces of the 'deft' package to make it look consistent
with the rest of the theme's relevant interfaces (to the extent
possible as Deft uses a non-standard presentation).
,* Aligned the 'speedbar-highlight-face' with the user option
'modus-themes-intense-mouseovers'.
,* Refined the 'highlight-thing' face (see package of the same name).
This makes it stand out more and it also aligns it with the standard
'match' face, which is pertinent here.
,* Amplified the saturation of the 'dired-git-info' face. Makes it
easier to differentiate the Git commit text from the Dired listing,
without drawing too much attention to itself.
,* Adjusted the hue of the 'easy-jekyll-help-face' from teal to blue.
This makes it look more like the standard 'help-key-binding' face,
although 'easy-jekyll' does not align with upstream Emacs in this
regard.
,* Intensified the background of 'rectangle-preview' to work even in
cases where a grey background is already on display. This face is
used for the 'string-rectangle' command (e.g. C-x SPC to draw a
rectangle and C-t to insert text in its stead---works as a simple
"multiple cursors" on a straight line).
Support for new faces or face groups
====================================
,* chart (built-in)
,* denote
,* edmacro-label (Emacs 29)
,* info+
,* leerzeichen
A comment on 'info+'. As is the case with PACKAGE+ packages from the
Emacs Wiki, info+ defines lots of faces that hardcode colour values
instead of inheriting from basic faces. It does so for no good reason
and the results will likely not look decent in any theme. Furthermore,
these faces colourise too much even when the colour values can be
appropriately combined (ceteris paribus), making the buffer harder to
read.
The support I add for info+ is consistent with the design principles of
the modus-themes, one of which is to avoid exaggerations as those
indirectly affect legibility. As such, some of the changes I introduce
here outright remove colouration, while others align the various
constructs with the overall aesthetic of the themes.
Note that, by default, info+ adds clickable buttons to glossary terms.
This produces awkward combinations such as by buttonising the "string"
component inside of what actually is a function's argument. So you
have, say, FORMAT-[STRING] where "[]" represents the button: the FORMAT
gets one face and the [STRING] another, even though they are part of a
single argument. To me this looks broken and is counter-productive,
though it is not up to the theme to decide how packages fontify the
various constructs. At any rate, button styles at the theme level are
controlled by the user option 'modus-themes-box-buttons'.
Thanks to Jonas Collberg for the feedback in issue 33 over at the GitHub
mirror: <https://github.com/protesilaos/modus-themes/issues/33>.
Miscellaneous
=============
,* Named the mailing list address as the =Maintainer:= of Denote.
Together with the other package headers, they help the user find our
primary sources and/or communication channels. This change conforms
with work being done upstream in package.el by Philip Kaludercic. I
was informed about it here:
<https://lists.sr.ht/~protesilaos/general-issues/%3C875ykl84yi.fsf%40posteo.net%3E>.
,* Addressed byte compilation warnings in doc strings pertaining to the
use of literal quotes. Thanks to Matt Armstrong and Rudolf Adamkovič
for the feedback on the mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87bktlvgyy.fsf@rfc20.org%3E>.
,* Fixed the ':link' value in the declaration of the user options
'modus-themes-operandi-color-overrides', 'modus-themes-vivendi-color-overrides'.
It once again directs to the correct heading in the manual.
,* Documented all the aforementioned, where necessary.
,* Mentioned my 'fontaine' and 'lin' packages in the relevant sections of
the manual. The former helps set fonts and switch between font
presents. The latter is a stylistic variant of hl-line (its
documentation explains its raison d'être).
#+end_src
* 2.4.0
:PROPERTIES:
:CUSTOM_ID: h:ee0dcce9-3481-4533-8ded-a9a1f5269a41
:END:
#+begin_src text
Modus themes version 2.4.0
By Protesilaos Stavrou <info@protesilaos.com> on 2022-06-01
This entry documents the changes made to the project since the
publication of version 2.3.0 on 2022-04-01. It spans more than 60
commits to an already stable project.
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 packaged version is available as
'modus-themes'.
Read the manual inside Emacs by evaluating:
(info "(modus-themes) Top")
Or visit: <https://protesilaos.com/emacs/modus-themes>.
Migration to SourceHut
======================
The sources of the project are as follows:
- Git repo on SourceHut: <https://git.sr.ht/~protesilaos/modus-themes>
- Mirrors:
- GitHub: <https://github.com/protesilaos/modus-themes>
- GitLab: <https://gitlab.com/protesilaos/modus-themes>
- Mailing list: <https://lists.sr.ht/~protesilaos/modus-themes>
- Official manual: <https://protesilaos.com/emacs/modus-themes>
- Change log: <https://protesilaos.com/emacs/modus-themes-changelog>
- Colour palette: <https://protesilaos.com/emacs/modus-themes-colors>
- Sample pictures: <https://protesilaos.com/emacs/modus-themes-pictures>
It is still possible to open issues on either of the mirrors and I will
handle them in a timely fashion, though I encourage you to at least try
the mailing list workflow---it is ordinary email (just remember to
"reply to all").
Further reading that is relevant to SourceHut:
- Moving all my Emacs projects to SourceHut:
<https://protesilaos.com/codelog/2022-04-07-all-emacs-projects-sourcehut/>
- Primer on formatting Git patches with Emacs (Magit):
<https://protesilaos.com/codelog/2022-04-09-simple-guide-git-patches-emacs/>
Problems with byte compilation on Emacs 29
==========================================
For some time between mid-April to mid-May, users of Emacs 29 could not
byte compile the Modus themes. This has now been fixed in emacs.git,
per bug#55414: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55414>.
Thanks to everyone involved (A-Z): Alan Mackenzie, Eli Zaretskii, Lars
Ingebrigtsen, Mattias Engdegård, Stefan Monnier.
Messages about invalid face attributes while using the centaur-tabs
===================================================================
I mentioned this issue in the previous change log as well: upstream does
not allow us to use indirection in faces (the ':inherit' attribute).
This is not our bug. It is standard behaviour for themes to use
inheritance.
I have an open pull request on the matter (since 2022-02-24):
<https://github.com/ema2159/centaur-tabs/pull/179>.
Relevant reports:
- <https://github.com/protesilaos/modus-themes/issues/30>
- <https://gitlab.com/protesilaos/modus-themes/-/issues/288>
- <https://github.com/protesilaos/modus-themes/issues/15>
Support for new faces or face groups
====================================
Directly supported
------------------
These are packages whose faces we override to make them work with the
themes.
- 'calibredb'. I have tried to limit the wanton use of colour in the
relevant buffers and also align the package with the overall style of
the themes. The currently selected line is affected by the user
option 'modus-themes-hl-line'.
Thanks to Ivan Popovych for the feedback on the official mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87zgkgroi7.fsf%40gmail.com%3E>.
Ivan also introduced some new faces to 'calibredb', which I helped
test. See: <https://github.com/chenyanming/calibredb.el/pull/60>.
- 'ein' (Emacs IPython Notebook). We support its code blocks with the
appropriate colouration, while avoiding exaggerations. Thanks to
Maxime Tréca for the feedback in issue 31 over at the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/31>.
- 'tree-sitter'. My intent was to reduce the overall colouration
produced by the default 'tree-sitter' faces. These tweaks give us
good results, though there still are some cases where 'tree-sitter'
exaggerates the styles it uses, such as by combining types with
constants to produce ad-hoc (anonymous) faces. We cannot do anything
about anonymous faces at the theme level. As such, we may get an
additional bold weight (when 'modus-themes-bold-constructs' is
non-nil) when we would rather not have it and/or a different colour
than the one desired.
Thanks to Przemysław Kryger for the feedback in issue 303 over at the
GitLab mirror: <https://gitlab.com/protesilaos/modus-themes/-/issues/303>.
If you are involved in the 'tree-sitter' project, please eliminate all
anonymous faces and replace them with symbols (i.e. defface) that are
editable by the user/theme. You are welcome to contact me if you need
help/ideas.
- 'vundo'
Indirectly supported
--------------------
These are packages that either (i) inherit from base faces we already
support, or (ii) use colours from the Modus themes' palette. A list of
them is available in the manual.
- egerrit. an in-development package by Niklas Eklund which provides an
Emacs interface to Gerrit: <https://git.sr.ht/~niklaseklund/egerrit>.
Changes to supported face
=========================
- Reworked the internal functions that handle the styling of diffs to
allow the user option 'modus-themes-deuteranopia' to combine with the
styles of the 'modus-themes-diffs' option.
Before, when 'modus-themes-deuteranopia' was non-nil it would affect
diffs by forcibly applying the default style of 'modus-themes-diffs'
(fairly prominent background colours) with the primary difference of
replacing greens with blues.
Now all combinations work as expected. For example:
(setq modus-themes-deuteranopia t
modus-themes-diffs 'desaturated) ; nil, 'desaturated, 'bg-only
Thanks to Kevin Le Gouguec for the feedback on the mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C878rqt4jhm.fsf@gmail.com%3E>
- Conducted a major (and highly demanding) review of the colours used by
Avy in the interest of optimising the contrast between its constructs.
Read the analysis: <https://protesilaos.com/codelog/2022-04-20-modus-themes-case-study-avy/>.
Thanks to Daniel Mendler and Damien Cassou for their feedback on the
mailing list:
- <https://lists.sr.ht/~protesilaos/modus-themes/%3C83f18e2e-d726-0248-72f5-95e896cbcf4c%40daniel-mendler.de%3E>
- <https://lists.sr.ht/~protesilaos/modus-themes/%3C87czhgt5nm.fsf%40cassou.me%3E>
- Updated the 'vertico-quick' faces to be consistent with Avy.
- Made the 'line-number' face conform with the user option
'modus-themes-mixed-fonts'. This means that if the user option is
non-nil, line numbers of 'display-line-numbers-mode' will use a
monospaced typeface at all times (inheriting the 'fixed-pitch' face,
as explained in the themes' manual). Otherwise they use whatever font
the 'default' face has. This makes it better when the user enables
'variable-pitch-mode' but still wants spacing-sensitive constructs to
remain monospaced.
Thanks to Christopher League for the feedback in issue 302 over at the
GitLab mirror: <https://gitlab.com/protesilaos/modus-themes/-/issues/302>.
- Aligned the regexp construct faces with the meaning of the user option
'modus-themes-bold-constructs'. They will use a bold weight only when
the user option is non-nil. This design is consistent with all other
aspects of syntax highlighting. These specific faces were
unconditionally bold due to a mistake of mine.
Remember to check the manual on what "a bold weight" means, as we make
everything easy to customise (e.g. if you prefer a semibold weight):
<https://protesilaos.com/emacs/modus-themes#h:2793a224-2109-4f61-a106-721c57c01375>.
- Removed the typographic emphasis from the 'file-name-shadow' face by
no longer inheriting the 'italic' face. Thanks to Nicolas De Jaeghere
for the patch.
[ Nicolas has assigned copyright to the Free Software Foundation. ]
- Stopped using the 'inverse-video' face attribute in 'powerline'. We
now apply the colours directly. The reason is that 'inverse-video'
makes it tricky to override the face as it swaps the foreground with
the background. That behaviour is only needed in special cases:
'powerline' is not one of them.
Thanks to Thibaut Verron for the feedback in issue 305 over at the
GitLab mirror: <https://gitlab.com/protesilaos/modus-themes/-/issues/305>.
- Ensured that git commit/rebase comments (as seen in the workflow of
the 'magit' package) inherit from appropriate font-lock faces. This
makes it possible to customise 'font-lock-comment-face' and have the
changes apply to those elements as well. Such a customisation can,
for example, involve the change of the font family or the addition of
a background colour. We want the whole comment block, including those
special keywords from Git, to look consistent. This change also makes
git-{commit,rebase}-comment-heading attain the foreground colour of
comments, instead of the default one (black or white), making it look
part of the comment block.
- Tweaked the 'fountain' package comments to be the same as all others.
This avoids inconsistencies, such as when the user opts for something
like the following:
(setq modus-themes-syntax '(yellow-comments))
- Disabled padding in the 'keycast' package, meaning that the box around
the key indicator always has the same height, even if the user opts
for a padding value in 'modus-themes-mode-line' (read the manual or
its doc string for how to assign a padding).
This is in response to a change upstream that introduces the
'keycast-tab-bar-mode', which re-uses the faces that were originally
intended for the mode line in the tab-bar. Ideally, upstream will
provide distinct faces for each context so that we can have padding in
the mode line but not the tab-bar. However, I have not had the
opportunity to suggest such a change and/or prepare the relevant patch
(it is not straightforward).
- Refined some colour combinations for the "alternative syntax" style
that is available when the user option 'modus-themes-syntax' includes
the 'alt-syntax' property. These tweaks pertain to changes in hue
that improve the appearance of certain faces in their context.
- Enabled conditional use of 'fixed-pitch' for key bindings. This
happens when the user option 'modus-themes-mixed-fonts' is non-nil
(all spacing-sensitive elements become monospaced even if the user
opts for a default font that is proportionately spaced or activates
the 'variable-pitch-mode'). Thanks to Manuel Giraud for the patch.
[ Manuel has assigned copyright to the Free Software Foundation. ]
- Covered the face rotation option of 'highlight-changes-mode'. It is
done with the 'highlight-changes-rotate-faces' command when
'highlight-changes-mode' is enabled (the mode is built into Emacs).
Thanks to Philip Kaludercic for the feedback on the mailing list:
https://lists.sr.ht/~protesilaos/modus-themes/<878rs14il4.fsf@posteo.net>
Updates to the manual
=====================
- Acknowledged Andrew Tropin as one of the contributors to the Guix
package of the Modus themes. The latest patch to that end:
<https://issues.guix.gnu.org/55268>.
- Rewrote the note on 'fill-column-indicator' to show how the user can
use a thicker line than the one we style by default.
- Wrote a note in manual about 'php-mode' multiline comments which use
the 'font-lock-doc-face' instead of 'font-lock-comment-face'. Sample
code is provided to ensure consistency between all types of comments.
- Added note about custom 'hl-todo' colours, specifically the user
option 'hl-todo-keyword-faces' (which the themes customise as an
exception to the rule, otherwise the default colours would not always
be accessible).
This is in relation to the mailing list thread on the matter with
feedback from Vincent Foley and Christian Tietze:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C871qwh1r88.fsf%40era.co%3E>.
- Elaborated on the style of 'git-gutter' faces in Doom Emacs, which are
not as the Modus themes intend. Basically, the problem is that Doom
changes the way that package draws its bitmaps: the faces we configure
no longer appear as intended and sensitive colouration is lost.
Thanks to Gonçalo Marrafa for reporting the issue, testing the code we
recommend on Doom Emacs, and suggesting the inclusion of the reference
to the 'after!' call (a macro that Doom defines).
Miscellaneous
=============
- Dedicated the colours of the Modus themes---just the colours---to the
public domain. The Emacs package as a whole is still distributed
under the terms of the GNU General Public License. The announcement:
<https://protesilaos.com/codelog/2022-05-10-modus-themes-palette-cc0/>
- Stopped using a timestamp in the modus-themes.el file. It could lead
to situations where there was a mismatch between the latest change and
the recorded time. It also introduced a barrier to entry for
contributors, as they need to set up 'time-stamp.el'.
- Removed the unnecessary 'require' call to the 'seq' library and made
the necessary changes. Thanks to Daniel Mendler for the patch.
[ Daniel has assigned copyright to the Free Software Foundation. ]
- Applied the correct order of inheritance for all markup faces. This
fixes a problem where not all typographic attributes where applied to
the faces when 'modus-themes-mixed-fonts' was non-nil and the value of
'modus-themes-markup' included '(bold italic)'.
- Tweaked how 'org-date' conditionally uses 'fixed-pitch'. Basically,
we remove an internal stylistic inconsistency. There is no
user-facing change. Thanks to Manuel Giraud for the patch.
- Implemented the command 'modus-themes-report-bug'. It might help
users find the email address of the mailing list and get started with
the email-centric workflow of SourceHut. Note this is but a first
step in that direction. If you think it can be improved, please
report as much (or send a patch).
- Included the command 'modus-themes-version', which prints in the echo
area the current version of the package. With an optional prefix
argument, it inserts the string at point.
The version either is the last tagged release, such as '2.4.0', or an
in-development version like '2.5.0-dev'. As we use semantic
versioning, tags of the '2.4.1' sort are not considered: those would
count as part of '2.5.0-dev'.
#+end_src
* 2.3.0
:PROPERTIES:
:CUSTOM_ID: h:f95fb7e2-fcc8-43f6-bde5-27fe51b1bdd5
:END:
#+begin_src text
Modus themes version 2.3.0
By Protesilaos Stavrou <info@protesilaos.com> on 2022-04-01
This entry documents the changes made to the project since the
publication of version 2.2.0 on 2022-02-23. It spans more than 70
commits.
To access the URL of the manual visit:
<https://protesilaos.com/emacs/modus-themes>. Or read it in the Emacs
Info reader by evaluating:
(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.
Customisation options
=====================
,* The 'modus-themes-completions' now accepts a 'text-also' property for
the 'selection' key. This has the effect of colourising the current
line's text. Whereas the default does not change the text colour,
re-using whatever underlying colours are available. Consult the doc
string of this user option, as it provides for fine-grained control of
how completion UIs may look. Thanks to Morgan Willcock whose feedback
in issue 278 inspired me to add the 'text-also' property:
<https://gitlab.com/protesilaos/modus-themes/-/issues/278>.
,* The 'modus-themes-box-buttons' now accepts an 'all-buttons' property.
It applies whatever other style is used for the boxed buttons to the
generic 'widget.el'. By default, the faces of 'widget.el' do not look
like graphical buttons: they have a bold weight and a foreground
colour instead. Examples where those are used are the Notmuch "hello"
buffer and the main view of the 'elfeed-summary' package. Thanks to
Daniel Mendler, Rudolf Adamkovič, and Tony Zorman for their feedback
in issue 296: <https://gitlab.com/protesilaos/modus-themes/-/issues/296>.
,* The 'modus-themes-intense-mouseovers' is a boolean user option which
makes mouse hover effects more intense when set to a non-nil value.
By default, mouseovers use a cyan background value. This changes it
to a more prominent blue. Thanks to John Haman for the feedback in
issue 290: <https://gitlab.com/protesilaos/modus-themes/-/issues/290>.
,* The user options 'modus-themes-box-buttons', 'modus-themes-mode-line',
'modus-themes-org-agenda', and 'modus-themes-headings' can now read a
number value as a cons cell. The old method of a plain number
continues to work. This makes it possible to be more descriptive on
what a given value signifies. Each doc string describes the
technicalities. Here are samples that yield identical results:
(setq modus-themes-mode-line '(accented 0.9 borderless 2))
(setq modus-themes-mode-line '(accented (heigh 0.9) borderless (padding 2)))
Thanks to Daniel Mendler for proposing this idea in issue 282:
<https://gitlab.com/protesilaos/modus-themes/-/issues/282#note_842257619>
Attempted bug fix for byte compiled files
=========================================
Quoting from the git log:
commit f067d2ef39c22174b95584f2cba7942aaf03bcca
Author: Protesilaos Stavrou <info@protesilaos.com>
Date: Thu Mar 3 06:52:31 2022 +0200
Reify themes with eval-and-compile
This is an attempt to fix a bug that has existed since version 1.2.0 of
the themes or even earlier.
The bug is about a mismatch between compiled code and runtime
dependencies. The runtime expects the current version while the
compiled code only furnishes an outdated one, thus resulting in an
error. This only happens when:
1. Private functions change to accept more/fewer arguments.
2. Variables change their acceptable value (e.g. from symbol to list).
3. The user is installing the package via the package.el mechanism which
takes care of byte compilation (though anything that mimics
package.el should exhibit the same behaviour).
My understanding is that the cause was the limited scope of the
'eval-and-compile' we had before: it would run the 'require' also at
compile time, whereas the 'modus-themes-theme' macro, which reifies the
actual theme, would only be evaluated at runtime. Hence the mismatch as
'require' would read the already installed byte code while the macro
would expect newer forms.
Wrapping everything in the 'eval-and-compile' should address this
problem. Hopefully it will not engender new ones...
,* * *
The latest reports about this bug:
,* GitLab issue 287 with Mark Bestley and Daniel Mendler:
<https://gitlab.com/protesilaos/modus-themes/-/issues/287>.
,* GitHub issue 22 with Rytis Paškauskas:
<https://github.com/protesilaos/modus-themes/issues/22>.
doc/modus-themes.info | 30 +++++++++++++++---------------
doc/modus-themes.org | 15 ++++++++-------
modus-operandi-theme.el | 10 +++++-----
modus-vivendi-theme.el | 10 +++++-----
4 files changed, 33 insertions(+), 32 deletions(-)
After nearly one month, no problem has been observed as a result of this
change.
Newly supported packages
========================
These are added to the already comprehensive coverage we guarantee.
Directly supported:
,* devdocs. Thanks to Augusto Stoffel, its developer, for the feedback
which was sent via email.
,* mini-modeline. Thanks to Julio C. Villasante for the feedback in
issue 24 over at the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/24>.
Indirectly supported (they use faces that we already cover):
,* elfeed-summary
,* undo-hl
Changes to supported faces or packages
======================================
,* Improved the colours used by 'avy' to always guarantee constrast in
hueness between side-by-side characters with a variety of user
settings. I tried various styles, such as:
(setq avy-style 'pre)
(setq avy-style 'at-full)
For the sake of completeness, I also ran tests by modifying the
'avy-lead-faces' (which is a 'defconst', not a 'defcustom'):
(setq avy-lead-faces
'(avy-lead-face
avy-lead-face-0
avy-lead-face-2
avy-lead-face
avy-lead-face-0
avy-lead-face-2))
(setq avy-lead-faces
'(avy-lead-face
avy-lead-face-1
avy-lead-face-1
avy-lead-face-1
avy-lead-face-1))
(setq avy-lead-faces
'(avy-lead-face
avy-lead-face-2
avy-lead-face-2
avy-lead-face-2
avy-lead-face-2))
,* Updated the 'vertico-quick' faces to keep them aligned with the new
Avy styles. Thanks to Daniel Mendler (Vertico's developer) for the
reminder:
<https://gitlab.com/protesilaos/modus-themes/-/commit/404a9658196debdde95a51148fc62c5b2faccfb9#note_856454659>.
,* Applied warmer though still not saturated colours for Org clocking
overlays. The previous style could be mistaken for a mouse highlight
or the highlighted line if 'modus-themes-hl-line' included the
properties 'intense' and 'accented'. Thanks to Rudolf Adamkovič for
the feedback in issue 293:
<https://gitlab.com/protesilaos/modus-themes/-/issues/293>.
,* Broadened coverage of the built-in 'shr.el' library to include the new
'shr-code' face (Emacs 29).
,* Expanded support for the 'embark' package by covering its new
'embark-collect-marked' face. Thanks to Daniel Mendler for the
feedback in issue 299:
<https://gitlab.com/protesilaos/modus-themes/-/issues/299>.
,* Made the 'fill-column-indicator' a contiguous line. It was a dashed
line before, per the Emacs defaults, which led to awkward results
depending on the font family and value of 'line-spacing'. Thanks to
Daniel Mendler for the feedback in issue 297:
<https://gitlab.com/protesilaos/modus-themes/-/issues/297>.
,* Added explicit support for the built-in 'separator-line' face in order
to refine its presentation. This is present in 'M-x shortdoc' buffers
(Emacs 28). Thanks to Daniel Mendler for the feedback in issue 297:
<https://gitlab.com/protesilaos/modus-themes/-/issues/297>.
,* Applied explicit styling to the generic 'underline' face in order to
ensure its consistent colouration. The problem before was that an
underline that spanned text with distinct colours would inherit the
colour of the affected character. A uniform presentation makes
everything easier to read.
,* The 'ement.el' Matrix client now uses a subtle background for username
mentions and/or quoted text. This is consistent with how other Matrix
clients style such constructs. Thanks to Adam Porter (aka
"alphapapa"), the developer of ement.el, for explaining the
technicalities and providing the relevant feedback in issue 25 over at
the GitHub mirror: <https://github.com/protesilaos/modus-themes/issues/25>.
,* Enforced consistency between 'icomplete' and 'ido'. The first match
was coloured differently in 'ido-mode' by mistake. Thanks to Morgan
Willcock for the feedback in issue 278:
<https://gitlab.com/protesilaos/modus-themes/-/issues/278>.
,* Used the main foreground for Company's tooltip. This is how it should
have been. Corfu is designed that way as well. Thanks to user okamsn
for the feedback in issue 278:
<https://gitlab.com/protesilaos/modus-themes/-/issues/278>.
,* Corrected an omission whereby the AUCTeX verbatim face was not
consistent with other such faces. Now it too is governed by the user
option 'modus-themes-markup'.
,* Fixed the 'centaur-tabs' invalid background message. Thanks to
Lennart C. Karssen for reporting the bug in issue 288:
<https://gitlab.com/protesilaos/modus-themes/-/issues/288>. Note,
however, that the problem is due to some decisions made upstream. My
patch has not been merged yet (open since 2022-02-24):
<https://github.com/ema2159/centaur-tabs/pull/179>. Given this
opportunity, always anticipate that faces may ':inherit' from others
and thus functions like 'face-background' might return an undesirable
nil value if used without a fallback.
Miscellaneous
=============
,* Made the 'modus-themes--current-theme' return the first Modus theme
instead of the 'car' of 'custom-enabled-themes'. This makes the
themes work at all times even when the user has multiple of them
enabled. Thanks to Pierre Téchoueyres for the patch, which was sent
via email with regard to Emacs bug#54598:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54598>.
,* Implemented compile-time requirement for built-in libraries to be sure
that the themes work in all cases. Thanks to Antonio Hernández Blas
for reporting in issue 292 the bug with the old design that assumed
the 'cl-lib' and 'subr-x' as already loaded:
<https://gitlab.com/protesilaos/modus-themes/-/issues/292>.
,* Wrote in the manual how to achieve a monochrome style (with
permutations) for code syntax highlighting. Thanks to Augusto Stoffel
for sharing the idea via an email exchange (this information is
divulged with permission).
,* Clarified some statements in the manual's section about the nuances in
"enabling" and "loading" a theme.
,* Documented how the applicable palette affects the outer boundaries of
the colour range that terminal emulators set when Emacs is ran without
a GUI. Here "the palette" refers to the relevant 16 ANSI escape
sequences (terminal colours 0 through 15). For the sake of
convenience, the node includes ready-to-use palettes for XTerm, which
can be adapted to other terminal emulators. This entry complements an
existing one on improving the colour accuracy in terminal emulators.
,* Used American English constructions in a few places such as "color"
instead of "colour" as that is what core Emacs expects (and the themes
are part of emacs.git).
,* Updated the description of the themes to be more user-friendly.
Instead of "Highly accessible themes (WCAG AAA)" we now have "Elegant,
highly legible and customizable themes". Nothing changes in terms of
substance. Thanks to Jorge Morais for the feedback.
,* Clarified that the version of the themes which is built into Emacs
does not use 'require'. It is in response to this thread:
<https://lists.gnu.org/archive/html/help-gnu-emacs/2022-03/msg00049.html>.
Thanks to Philip Kaludercic for bringing the issue to my attention.
,* Improved the code samples that show how to set up the package.
,* Wrote the correct symbols for some obsoletion forms.
Thanks once again to everyone involved!
#+end_src
* 2.2.0
:PROPERTIES:
:CUSTOM_ID: h:251849ee-3328-48c7-af5f-d1d6daca3a97
:END:
#+begin_src text
Modus themes version 2.2.0
By Protesilaos Stavrou <info@protesilaos.com> on 2022-02-23
The present entry records the changes made to the project since the
publication of version 2.1.0 on 2022-02-17. This spans about 10 commits
(though one of them is massive). Normally the release cycle occurs over
periods of 4-5 weeks. This is a necessary exception.
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.
Initialisation of user options
==============================
Removed a superfluous default value that hampered the initialisation of
defcustom forms in the M-x customize interface. Things would still
work, but the interface was not looking right while editing the relevant
variables. Thanks to Gustavo Barros for reporting the bug in issue 267:
<https://gitlab.com/protesilaos/modus-themes/-/issues/267>.
Refactor 'modus-themes-completions'
===================================
Implemented thoroughgoing reforms across all completion User Interfaces
(UIs) in order to make them more flexible/powerful and harmonise their
looks.
'modus-themes-completions' now accepts an alist instead of a symbol.
Each cons cell is in the form of '(key . list-of-properties)'. The doc
string describes all the details.
In terms of out-of-the-box appearences, all completion UIs have a subtle
aesthetic. This was always the case for the likes of Vertico, Icomplete
(Fido), and related, though it constitutes a marked departure from what
Ivy and Helm used to look like. Users of the latter two can still get
the more colourful or intense style with something like this:
(setq modus-themes-completions '((matches . (background intense))
(selection . (accented intense))
(popup . (accented intense))))
Or simply:
(setq modus-themes-completions '((t background intense accented)))
The documentation explains all those associations in-depth. There also
are other styles on offer (and combinations thereof).
Furthermore, the new 'modus-themes-completions' encompasses more UIs
than its predecessor, including Company and Corfu.
In the interest of theme-wide consistency, all applicable faces have
been reviewed.
Finally, note that the previous tagged release also made changes on this
front, but it did not disrupt the status quo that was in place from
before the release of version 1.0.0 of the themes (more than a year
ago). In other words, it tried to make unnecessary compromises within
the confines of an outdated design that did not fit in with the rest of
the code base. The new 'modus-themes-completions' might require manual
intervention from users who want to customise things to their liking,
though I feel this change is to our long-term benefit.
Thanks to Daniel Mendler and Rudolf Adamkovič for their feedback in
issue 278: <https://gitlab.com/protesilaos/modus-themes/-/issues/278>.
And thanks to Kenta Usami for recommending the use of a warning in issue
286: <https://gitlab.com/protesilaos/modus-themes/-/issues/286>.
Miscellaneous changes
=====================
+ Removed the pseudo-button effect from the 'org-checkbox' face. It was
not up-to-date with the current style of the rest of the themes,
including the Org constructs for source block delimiters, the TODO
keywords, the priority cookies (e.g. '[#A]'), and others.
+ Introduced a section in the manual which provides an alternative to
the standard 'modus-themes-toggle' that leverages 'enable-theme'
instead of 'load-theme' under the hood. These technicalities are all
explained in the manual.
+ Provided an alternative greyscale palette subset for 'modus-operandi'
in the manual's section about overriding colours.
+ Added support for the built-in 'custom-variable-obsolete' face.
+ Fixed typo in the 'modus-themes-box-buttons' variable. Thanks to
Illia Ostapyshyn for the patch in merge request 58:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/58>.
#+end_src
* 2.1.0
:PROPERTIES:
:CUSTOM_ID: h:15098250-7b41-404b-86e1-9a99984976b9
:END:
#+begin_src text
Modus themes version 2.1.0
By Protesilaos Stavrou <info@protesilaos.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.
Commands
========
The following produce a buffer that previews the colour palette of the
given theme ('modus-operandi' or 'modus-vivendi').
,* 'modus-themes-list-colors' prompts for a theme before producing the
preview.
,* 'modus-themes-list-colors-current' uses 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.
Customisation options
=====================
,* Implemented the 'modus-themes-markup' variable, 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 =verbatim=, ~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:
1. 'italic' for an added slant to the text.
2. 'bold' for a heavier weight.
3. 'background' to add a background colour.
4. 'intense' to amplify the colouration (especially of 'background').
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>.
,* Added the 'modus-themes-box-buttons' which 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:
1. 'flat' to remove the 3D effect.
2. 'accented' to shift the colouration away from grey.
3. 'faint' to reduce the overall colouration (e.g. grey becomes white).
4. 'variable-pitch' to apply a proportionately spaced font.
5. 'underline' to draw a line instead of applying a 3D or flat box
(particularly useful for those who use Emacs in a terminal emulator).
6. The symbol of a font weight, such as 'bold', 'semibold', 'light' or
any one among those included in the 'modus-themes-weights' constant
(the underlying font family has to support the given weight).
7. 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 'underline' and 'flat' are 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>.
,* Expanded the 'modus-themes-mail-citations' with an 'intense' variant.
For example:
(setq modus-themes-mail-citations 'intense)
The default is a moderately coloured style. Other variants include
'faint' for subtle colouration and 'monochrome' for an all-grey look.
,* Reviewed the 'modus-themes-completion' option and harmonised all the
face specifications it governs. The variable now accepts a fourth
stylistic variant in 'super-opinionated': it is like the 'opinionated'
one 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. ]
- The (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".
- The (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.
- The (setq modus-themes-completions 'opinionated) should be the same
as before, notwithstanding the aforementioned tweaks to Ivy/Helm.
- The (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.
Miscellaneous:
- 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:
- <https://gitlab.com/protesilaos/modus-themes/-/issues/214>
- <https://gitlab.com/protesilaos/modus-themes/-/issues/278>
,* Adjusted the applicable hues in some 'modus-themes-syntax' variants. In
particular:
- The strings' hue has more hints of blue when 'modus-themes-syntax'
includes the 'green-strings' property. 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 'modus-themes-syntax'
includes the 'alt-syntax' property 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.
,* Removed background colours from the the default style of Org block
delimiters.
As I explained in Emacs bug#52587,[1] 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-blocks' provides "blocky" alternatives that use
background colours---those extend to the edge of the window.
[1] <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52587#46>
,* 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")
Or visit: <https://protesilaos.com/emacs/modus-themes#h:bf1c82f2-46c7-4eb2-ad00-dd11fdd8b53f>.
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
===================================
,* all-the-icons-dired.
,* all-the-icons-ibuffer.
,* 'child-frame-border' face (Emacs 28).
,* 'citar' package. 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>.
,* 'mct' package.
,* 'menu' face (built-in) which is used in the menu-bar when Emacs runs
without a graphical toolkit.
,* 'pgtk-im-0' face (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).
,* 'slime' and 'sly' packages. 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.
,* 'textsec' package (Emacs 29).
New indirectly supported packages
---------------------------------
These inherit from base faces and look good enough already or use
appropriate colours from the Modus themes:
,* dtache
,* org-remark
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-binding'
face (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-key' package 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 'transient' and '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"))
,* Made 'transient' faces which are supposed to be de-emphasise certain
elements inherit the 'shadow' face. 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 'shadow' face.
,* Covered the 'transient-purple' face (these are like the colour-coding
of 'hydra').
,* Tweaked the 'transient-argument' and 'transient-value' faces 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 'marginalia-key'
('marginalia' package) and 'embark-keybinding' ('embark' package).
They inherit the 'modus-themes-key-binding' when 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-sectioning'
which 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-icons' and 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 'modus-themes-headings'.
,* Included new 'telega-entity-type-spoiler' face. 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 '#49d239'->'#49c029'
or '#7fcfff'->'#8fbfff'.
,* Tweaked the hues of all graph colours, which are used in the
'org-habit' table. 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>.
,* Styled the 'markdown-highlighting-face'. This is the face used for
text in between double equals signs when the user option
'markdown-enable-highlighting-syntax' is non-nil.
,* 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 'geiser-font-lock-autodoc-current-arg' and
'geiser-font-lock-autodoc-identifier').
,* Made the 'keycast-key' face work when 'modus-themes-mode-line' has a
padding value (read the latter doc string or consult the manual).
,* Refined the 'magit' faces for bisect, reflog, sequence, and signature
views. They get a bold weight and, where appropriate, are made to
comply with the 'modus-theems-deueteranopia' option (meaning that
greens turn into blues).
,* Recoloured 'elfeed' tags 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 italic' from the 'italic' face, which is
consistent with how we do not hardcode ':weight bold' in the 'bold'
face.
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 'highlight' face across all
contexts (typically used for mouse hover effects). The mode line has
an exception when its style includes an accented background (per
'modus-themes-mode-line').
Thanks to Rudolf Adamkovič for the feedback in issue 214:
<https://gitlab.com/protesilaos/modus-themes/-/issues/214>.
,* Changed the foreground of 'mode-line-emphasis' from blue to purple, in
order to avoid potential (albeit unlikely) confusion with other
indicators.
,* Desaturated the 'man' and 'woman' foreground 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-field' does not need to ':extend', as that typically does
not look good.
- 'custom-state' gets a warmer colour to convey its message more
effectively.
- 'eww-form-text' no longer uses a ':box' because that breaks when the
widget occupies more than one line.
- 'eww-form-textarea' can now inherit from 'eww-form-text'.
Thanks to Daniel Mendler for the feedback on the style of those faces in
issue 284: <https://gitlab.com/protesilaos/modus-themes/-/issues/284>.
The manual
==========
,* Clarified the wording of 'shr' fonts, which affect 'eww', 'elfeed',
'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:
- <https://protesilaos.com/codelog/2022-01-03-modus-themes-port-faq/>.
- <https://protesilaos.com/codelog/2022-01-23-base16-modus-themes/>.
,* 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>.
Miscellaneous
=============
,* 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-vivendi' face 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-line' from 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>.
,* Recalibrated the 'modus-vivendi' named colour 'bg-paren-match'.
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-themes-contrast').
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):
- <https://gitlab.com/protesilaos/modus-themes/-/issues/269>.
- <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/56>.
,* Fixed typo in the ':group' value 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.
#+end_src
* 2.0.0
:PROPERTIES:
:CUSTOM_ID: h:46d92baa-eff3-4973-bac0-cf762b457e2d
:END:
#+begin_src text
Modus themes version 2.0.0
By Protesilaos Stavrou <info@protesilaos.com> on 2021-12-24
This entry covers the changes made to the project since the publication
of version 1.7.0 on 2021-11-18. There have been more than 90 commits in
the meantime. This is a major upgrade with some backward-incompatible
changes, even though most work was done behind the scenes (i.e. not in
git commits but local testing) to guarantee the relevance of all
user-facing styles, code practices, et cetera.
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.
A fully fledged org-mode file with the annotated task list for Modus
themes version 2.0.0 is supplied as complementary material to the
present entry. It should be annexed below this text on the announcement
page: <https://protesilaos.com/codelog/2021-12-24-modus-themes-2-0-0/>.
Customisation options
=====================
There are some breaking changes that were necessary to improve the code
base and make things easier as well as more efficient for end users.
Please read carefully and apologies in advance for whatever
inconvenience.
,* The 'modus-themes-variable-pitch-headings' no longer has any effect.
Instead, users can specify a 'variable-pitch' property to the list
they pass to the 'modus-themes-headings' or 'modus-themes-org-agenda'
(examples below).
,* All 'modus-themes-scale-*' options are removed. Scaling of headings
is now handled directly by the user options 'modus-themes-headings'
and 'modus-themes-org-agenda' (code samples below).
,* The 'modus-themes-headings' option now accepts a floating point (see
function 'floatp') that represents the multiplier relative to the base
font size. This can be used to scale headings accordingly. Since
this option can target individual heading levels (for 1 through 8),
users can now implement their desired scale with greater precision.
Whereas before it was limited to the first four levels, admittedly for
no good reason.
The newly introduced 'variable-pitch' property can also be applied on
a per-level basis (making it easy to combine with existing properties,
such as a custom weight, for maximum control). Example:
;; This is an alist: read the manual or its doc string.
(setq modus-themes-headings
'((1 . (variable-pitch light 1.6))
(2 . (overline semibold 1.4))
(3 . (monochrome overline 1.2))
(4 . (overline 1.1))
(t . (rainbow 1.05))))
,* The 'modus-themes-org-agenda' follows the same design as the
'modus-themes-headings' where appropriate. Headings that can be
scaled accept a floating point, while those that may be rendered in a
proportionately spaced font accept the 'variable-pitch' property. In
addition, a custom font weight is also supported in the relevant
places (just as with 'modus-themes-headings'). Overall, the interface
can now be tailored to the user's preferences with greater precision.
;; This is an alist: read the manual or its doc string.
(setq modus-themes-org-agenda
'((header-block . (variable-pitch light 1.6))
(header-date . (bold-today grayscale underline-today 1.2))
(event . (accented varied))
(scheduled . uniform)
(habit . traffic-light)))
,* The 'modus-themes-scale-small' that was used in the Org agenda
interface has been removed. No replacement is provided, as the
downsizing had the undesired effect of breaking the otherwise neat
alignment of elements on the grid.
,* The 'modus-themes-mode-line-padding' option has been removed.
Instead, users can specify a natural number (positive integer)
directly in the list of properties passed to the
'modus-themes-mode-line' variable. This has no effect when the
'moody' property is also set, because the Moody library applies its
own padding. For example:
(setq modus-themes-mode-line '(borderless accented 4))
Though not related to changes on our end, users of Emacs 29 must now
set 'x-use-underline-position-properties' to nil for padding to work
properly (due to other adjustments upstream). This relates to Emacs
bug#52324 we had reported:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52324>.
,* All deuteranopia styles are consolidated in a single toggle:
'modus-themes-deuteranopia'. The 'modus-themes-success-deuteranopia'
is thus rendered obsolete and superseded, while the individual
deuteranopia-friendly styles for diffs ('modus-themes-diffs') and the
Org agenda's habit graph ('modus-themes-org-agenda') are altogether
removed. As opposed to top-level forms, there is no clean way to
notify the user of the deprecation of individual values of a user
option.
,* The "foreground only" style has been altogether removed from the user
option 'modus-themes-diffs'. It never was up to the aesthetic
standard of the themes even though the colours met the minimum 7:1
contrast ratio. There is a new section in the manual which documents
how to implement such a style with user-level configurations. Short
version:
(defun my-modus-themes-custom-faces ()
(modus-themes-with-colors
(custom-set-faces
`(modus-themes-diff-added ((,class :background unspecified :foreground ,green))) ; OR ,blue for deuteranopia
`(modus-themes-diff-changed ((,class :background unspecified :foreground ,yellow)))
`(modus-themes-diff-removed ((,class :background unspecified :foreground ,red)))
`(modus-themes-diff-refine-added ((,class :background ,bg-diff-added :foreground ,fg-diff-added)))
;; `(modus-themes-diff-refine-added ((,class :background ,bg-diff-added-deuteran :foreground ,fg-diff-added-deuteran)))
`(modus-themes-diff-refine-changed ((,class :background ,bg-diff-changed :foreground ,fg-diff-changed)))
`(modus-themes-diff-refine-removed ((,class :background ,bg-diff-removed :foreground ,fg-diff-removed)))
`(modus-themes-diff-focus-added ((,class :background ,bg-dim :foreground ,green))) ; OR ,blue for deuteranopia
`(modus-themes-diff-focus-changed ((,class :background ,bg-dim :foreground ,yellow)))
`(modus-themes-diff-focus-removed ((,class :background ,bg-dim :foreground ,red)))
`(modus-themes-diff-heading ((,class :background ,bg-alt :foreground ,fg-main)))
`(diff-indicator-added ((,class :foreground ,green))) ; OR ,blue for deuteranopia
`(diff-indicator-changed ((,class :foreground ,yellow)))
`(diff-indicator-removed ((,class :foreground ,red)))
`(magit-diff-added ((,class :background unspecified :foreground ,green-faint)))
`(magit-diff-changed ((,class :background unspecified :foreground ,yellow-faint)))
`(magit-diff-removed ((,class :background unspecified :foreground ,red-faint)))
`(magit-diff-context-highlight ((,class :background ,bg-dim :foreground ,fg-dim))))))
;; This is so that the changes persist when switching between
;; modus-operandi and modus-vivendi
(add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-custom-faces)
Removed support for packages
============================
The following are no longer supported by the themes. The reasons vary
in each case, though they boil down to (i) the package being obsoleted,
or (ii) the package's faces inheriting from base faces that we already
support (e.g. font-lock). Each case was carefully considered as part of
the comprehensive review of all packages supported by the themes, though
chances are that some mistake was made regardless. If you believe a
package should not have been removed, please report as much.
,* ag
,* apt-sources-list
,* apt-sources-list
,* buffer-expose
,* counsel-org-capture-string
,* define-word
,* diredc
,* disk-usage
,* easy-kill
,* flyspell-correct
,* git-gutter{,fringe}+
,* git-lens
,* git-walktree
,* highlight-blocks
,* highlight-defined
,* highlight-escape-sequences
,* highlight-symbol
,* highlight-tail
,* hyperlist-mode
,* isl (isearch-light)
,* minibuffer-line
,* mu4e-conversation
,* no-emoji
,* objed
,* parrot
,* phi-search
,* pkgbuild-mode
,* rainbow-identifiers
,* sallet
,* spell-fu
,* spray
,* swoop
,* vdiff
,* volatile-highlights
Changes to supported faces or face groups
=========================================
,* Eliminated any possible exaggerations in wgrep faces. Those no longer
use coloured backgrounds. Instead they have colour-coded foreground
colours as well as a bold weight (they ultimately inherit from the
'bold' face, which is a "hidden" customisation option, as explained in
the manual).
,* Forced Org block delimiters to not extend their background by default
(though check 'modus-themes-org-blocks'). That was the intended
design all along, but now it needs to be made explicit. See, for
example, bug#52587 for Emacs:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52587>
,* Revised the 'org-sexp-date' face so that it no longer looks like
'org-date'. Dates are clickable buttons: they work like links, so
they have an underline by default and are subject to the
'modus-themes-links' user option. Whereas the 'org-sexp-date' is not
applied to interactive elements and must thus be visually distinct.
This face is used for diary-style entries in Org files. For example:
%%(diary-anniversary 2000 12 25) NAME %d%s birthday
,* Rewrote several Auctex/Tex faces to inherit from base faces where
relevant (e.g. 'bold', 'success') as well as from font-lock faces. In
the latter case, the end-result makes Auctex/Tex subject to the
'modus-themes-syntax' option. These refinements promote theme-wide
consistency without detracting from the established styles.
,* Improved Git (Magit) commit faces for warnings or errors. This
concerns two cases:
1. The summary line exceeds the recommended limit of 50 characters.
This now uses a yellow foreground colour which contrasts well with
the summary line's new blue hue (blue and yellow are complementary
for our purposes, meaning that they have good contrast in hueness).
2. The second line (the one right below the summary) has text that
should not be there. This one is coloured in a shade of red, which
again contrasts well with blue.
Thanks to Damien Cassou for noticing in issue 261 that the previous
style of applying tinted backgrounds did not work well when
'hl-line-mode' was enabled ('hl-line-mode' overrides backgrounds and
so the warnings/errors where not always obvious):
<https://gitlab.com/protesilaos/modus-themes/-/issues/261>.
,* Added support for the new 'magit-branch-warning' face that we helped
upstream define: <https://github.com/magit/magit/issues/4550>. It
disambiguates warnings in Magit status buffers from the generic and
often inappropriate for such a context 'font-lock-warning-face'.
,* Simplified all the Apropos faces. They no longer look like buttons or
links as that makes the presentation of 'M-x apropos' very busy.
Instead, they now only have a foreground colour.
,* Updated support for org-roam faces by removing old entries and
covering new ones.
,* Replaced old company-mode faces with their new aliases:
- company-scrollbar-bg => company-tooltip-scrollbar-thumb
- company-scrollbar-fg => company-tooltip-scrollbar-track
,* Made 'org-column-title' inherit from 'fixed-pitch' when the user
option 'modus-themes-mixed-fonts' is non-nil. This is needed to line
up columns correctly. Thanks to Björn Lindström for the contribution
in merge request 52:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/52>.
,* Forced the 'org-colview' faces to use the same height, even when
headings are scaled (see 'modus-themes-headings'). This ensures that
the columns are aligned properly and text fits on the same row.
Thanks to Björn Lindström for the contribution in merge request 53:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/53>.
,* Refrained from applying a bold weight to the Org date selection
indicator in the calendar. The use of bold has the potential to create
problems with the alignment of dates for certain typefaces that do not
have a proper bold variant. Also, there is no need for added emphasis
given that we already use a prominent background colour.
,* Made 'M-x org-table-header-line-mode' or the third-party package
'org-table-sticky-header' use colours that fit better with those of
tables.
,* Removed explicit styling of the 'magit-branch-current' face because
its definition checks if the ':box' attribute can be set and if not, it
uses ':inverse-video'. Useful for terminal emulators.
,* Expanded support for the 'mode-line-active' face for Emacs29. The
face upstream basically adds proportionately spaced fonts (the
'variable-pitch' face) to the mode line. The themes can already use
that if the user option 'modus-themes-variable-pitch-ui' is non-nil.
Thanks to Manuel Uberti for the feedback in issue 257:
<https://gitlab.com/protesilaos/modus-themes/-/issues/257>.
,* Implemented some stylistic refinements for ERC and Rcirc to ensure
theme-wide consistency (e.g. timestamps are a shade of cyan).
,* Tweaked adoc-mode faces for stylistic theme-wide consistency.
,* Refashioned all the git faces of Treemacs so that they are more
consistent with other such contexts or uses. The new styles also
conform with the 'modus-themes-deuteranopia' option.
Miscellaneous
=============
,* Ended the wanton use of internal functions in places that did not
require them. Instead, the themes define faces that evaluate such
functions once and pass their results to the relevant entries. Cases
include:
- Symlink and/or broken link faces in contexts such as Dired,
Eshell, Helm, Trashed.
- Tabbed interfaces (tab-bar, tab-line, centaur-tabs).
- Verbatim markup or that of inline code in Org, Markdown, Asciidoc,
etc.
- The optional use of 'variable-pitch' for User Interface elements
(see 'modus-themes-variable-pitch-ui').
,* Refined the dedicated diff background colours of modus-vivendi that
are used when the user option 'modus-themes-deuteranopia' is non-nil.
The changes improve the distinction between all red and yellow
constructs in contexts where they appear together (e.g. smerge-mode).
Basically, yellows will look more bright, while reds appear as
brown. The corresponding blues are toned down a bit to be consistent
with the other colours. Consequently, the standard shades of green
for added lines (when 'modus-themes-deuteranopia' is nil) are
recalibrated to combine well with all other values.
,* Made several faces return an 'unspecified' value instead of nil for
their unused attributes under certain circumstances. This is to guard
against third-party code that unconditionally expects a non-nil value.
,* Omitted {over,under}line attributes from the mode line when the
'padded' property is added to the 'modus-themes-mode-line' user
option. Those are not necessary in that context. Thanks to Illia
Ostapyshyn for the contribution in merge request 54:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/54>
,* Rewrote several internal functions in the interest of consistency and
clarity.
,* Deleted two user options that were long obsolete: (i)
'modus-themes-org-habit' has been superseded by
'modus-themes-org-agenda' since version 1.5.0 of the themes and (ii)
'modus-themes-intense-hl-line' has been replaced by
'modus-themes-hl-line' since version 1.3.0.
,* Removed parentheses from headings in the manual as they are invalid
characters for some version of Texinfo. See Emacs bug#52126:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52126>.
,* Updated all doc strings so that quoted lists yield valid syntax in
Help buffers; syntax that can be directly evaluated (otherwise Emacs
prettifies straight quotes as curly ones, which break the code).
Thanks to Christian Tietze for bringing this issue to my attention:
<https://gitlab.com/protesilaos/modus-themes/-/issues/248#note_753169268>.
,* Rewrote all sections of the manual to document the current state of
the project as pertains to valid user options, explicitly supported
face groups, and so on.
#+end_src
* 1.7.0
:PROPERTIES:
:CUSTOM_ID: h:22de7065-f54c-4944-b47f-3cc8a30551c8
:END:
#+begin_src text
Modus themes version 1.7.0
By Protesilaos Stavrou <info@protesilaos.com> on 2021-11-18
The present entry records the changes made to the project since the
release of version 1.6.0 on 2021-09-29. There have been more than 60
commits since then.
Every modification pertaining to colour combinations referenced herein
is implemented 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).
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 from Emacs by
evaluating this form:
(info "(modus-themes) Top")
The themes are built into Emacs version 28 (next stable release), and
are available on GNU ELPA as well as other archives. This release is
the first one that is included with Emacs 29, or else the 'master'
branch in emacs.git.
Customisation options
=====================
+ The 'modus-themes-no-mixed-fonts' has been deprecated and replaced by
the 'modus-themes-mixed-fonts'. This is a breaking change for users
who want to use "mixed fonts": they must set the new variable to
non-nil.
As the name implies, the new variable changes the meaning of the
feature to make it opt-in by default. This is consistent with the
principle of least surprise, as users may not know why some fonts look
different than others in certain cases.
Thanks to Christian Tietze for clarifying the doc string of this new
user option in merge request 51:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/51>.
For context, "mixed fonts" refers to a design where spacing-sensitive
constructs, such as code blocks and Org tables, inherit from the
'fixed-pitch' face to remain monospaced (and properly aligned) at all
times. Depending on the user's configurations, the 'fixed-pitch' face
may not use the typeface that the user expects.
The manual provides information on how to set the desired fonts by
editing the 'default', 'fixed-pitch', and 'variable-pitch' faces.
+ The new 'modus-themes-mode-line-padding' can be used to control the
apparent padding of the mode line when the user option
'modus-themes-mode-line' includes the 'padded' property. The padding
must be a positive integer (otherwise the code would be needlessly
complex to guard against values that make the mode line look awkward,
like anything lower than -3 or maybe even -2).
Thanks to Guilherme Semente and Manuel Uberti for the feedback in
issue 245: <https://gitlab.com/protesilaos/modus-themes/-/issues/245>.
Note that the out-of-the-box style of the themes has a padding of 1
(technically a ':line-width' of 1 for the ':box' attribute), whereas
the default style of Emacs has it at -1. This is a design choice to
avoid an overlap between the outer boundaries of a font's glyphs and
the borders of the mode line, when using certain common typefaces at
various point sizes. Such an overlap can hinder readability.
The manual contains a new Do-It-Yourself (DIY) section with detailed
code samples on how to apply a negative value.
+ The new 'modus-themes-intense-markup' option can be set to non-nil to
make constructs such as inline code and verbatim text more colourful.
This has a general utility, though its consideration was prompted by a
phenomenon reported by Stefan Kangas in issue 238 where the overlay of
the 'hl-line-face' overrides the subtle background these constructs
use and can thus make them virtually indistinguishable from ordinary
text: <https://gitlab.com/protesilaos/modus-themes/-/issues/238>.
Such is the standard behaviour of 'hl-line-mode' and there is nothing
a theme can (or rather "should") do about it. Thanks to Stefan Kangas
for the feedback.
+ The 'modus-themes-headings' option can now accept and apply an exact
font weight such as 'semibold' or 'light'. (The list of available
weights is the value of the 'modus-themes--heading-weights' internal
variable.) This supersedes the now-deprecated 'no-bold' property:
'no-bold' is henceforth understood as the presence of a 'regular'
weight.
Recall that this user option is an alist and can be used to target
heading levels individually, which further reinforces the utility of
this new property.
Thanks to Christian Tietze for suggesting this idea in issue 248:
<https://gitlab.com/protesilaos/modus-themes/-/issues/248>. And
thanks to Daniel Mendler for refining its implementation in commit
54bfd62, which was sent as a patch file (yes, we accept those and I
actually prefer them over a web app's UI).
+ The 'modus-themes-org-agenda' has seen improvements to its 'event' key
(this is an alist that has multiple keys). It now accepts a 'varied'
property which differentiates between (i) plain timestamp entries and
(ii) entries that are generated from either the diary or a symbolic
expression. The 'varied' property combines with the other available
properties to particularise their effects. Consult the doc string or
the manual for the technicalities.
Thanks to Gustavo Barros for the detailed commentary in issue 241:
<https://gitlab.com/protesilaos/modus-themes/-/issues/241>.
+ The 'modus-themes-lang-checkers' now accepts a 'faint' property. This
has the effect of toning down the colours in use. By default, the
only colour is that of the underline, though more can be added by
combining the properties accepted by this user option. Consult its
doc string or the manual for further details.
Thanks to Morgan Smith for suggesting the idea in issue 239:
<https://gitlab.com/protesilaos/modus-themes/-/issues/239>.
Add support for new packages or face groups
===========================================
+ 'company-tooltip-deprecated' face. Thanks to Roman Rudakov for the
feedback in issue 247: <https://gitlab.com/protesilaos/modus-themes/-/issues/247>.
+ 'corfu-default' face. Thanks to Daniel Mendler (Corfu's developer)
for the feedback in issue 254:
<https://gitlab.com/protesilaos/modus-themes/-/issues/254>.
+ 'image-dired' package (Emacs 29). Thanks to Stefan Kangas for making it
happen in emacs.git and for the feedback in issue 250:
<https://gitlab.com/protesilaos/modus-themes/-/issues/250>.
+ 'nano-modeline' package.
+ 'vertico-quick' package. Thanks to Nicolas De Jaeghere for the
contribution in merge request 48:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/51>.
Changes to existing faces or face groups
========================================
+ Added support for the new Org agenda faces that improve the
contextuality of various views. We implemented those upstream for Org
version 9.5 in close cooperation with Gustavo Barros. Thanks to
Gustavo for the detailed feedback in issue 241:
<https://gitlab.com/protesilaos/modus-themes/-/issues/241>. The
thread about the patch upstream:
<https://list.orgmode.org/87lf7q7gpq.fsf@protesilaos.com/>
+ Refined Org agenda date faces in the interest of consistency and in
accordance with the aforementioned change. Thanks again to Gustavo
Barros for the discussion in issue 241.
+ Applied the 'shadow' face more consistently across all contexts where
only a subtle foreground value is expected. This design choice makes
it possible for users to manually edit the foreground colour of
'shadow' to something even more subtle than the 'fg-alt' palette
variable we use, which maps to a gray colour (e.g. they could use
"gray50").
+ Implemented a subtle background colour to the 'widget-inactive' face.
This makes it easier to discern inactive buttons, checkboxes, and the
like, in contexts such as the Customize User Interface. Thanks to
Stefan Kangas for the feedback in issue 242:
<https://gitlab.com/protesilaos/modus-themes/-/issues/242>.
+ Tweaked 'file-name-shadow' to also use italics (inherit from the
'italic' face) in order to be more easy to distinguish it from
ordinary text in the minibuffer.
Recall that the manual documents the meaning of inheriting from the
'bold' and 'italic' faces instead of hardcoding a bold weight and an
italic slant, respectively. In short: users can change the weight to
what they want (e.g. semibold) and/or use distinct font families.
+ Amplified the style of Version Control (VC) warnings and errors to let
them draw more attention to themselves (because these indicators need
to be acted upon).
+ Recoloured the 'custom-group-tag' face to make it fit better in its
context and be consistent with the rest of the themes' established
patterns.
+ Made marks for selection in Dired, Ibuffer, and related, conform with
the 'modus-themes-success-deuteranopia' option. This means that they
use blue colours when the option is non-nil, instead of their default
shades of green.
+ Adjusted the box width of key bindings for Emacs 28 or higher. They
should no longer cause any alignment issues. This style is now used
throughout the themes, including in transient views (e.g. Magit) which
were the exception before. Thanks to Manuel Uberti and Kevin Fleming
for the feedback in issue 232:
<https://gitlab.com/protesilaos/modus-themes/-/issues/232>.
Miscellaneous
=============
+ Wrote a brief description of every user option in the manual. Also
covered its type, as in boolean, alist, et cetera.
+ Corrected the mode line border width for one combination of properties
in the 'modus-themes-mode-line' option. This should now have the same
height as all others:
(setq modus-themes-mode-line '(accented borderless))
+ Ensured that mode line attributes would not be set to nil, but kept at
an 'unspecified' value instead, where relevant. This avoids problems
with [faulty] code that unconditionally depends on something that does
not exist, as in the following while ':box' is nil:
(face-attribute 'mode-line :box)
+ Expanded, reworded, or otherwise improved the manual, based on the
aforementioned.
Thanks once again to everyone involved!
#+end_src
* 1.6.0
:PROPERTIES:
:CUSTOM_ID: h:e4b9945c-1db8-4626-abc9-372469b19253
:END:
#+begin_src text
Modus themes version 1.6.0
By Protesilaos Stavrou <info@protesilaos.com> on 2021-09-29
This entry records the changes made to the project since the release of
version 1.5.0 on 2021-07-15. There have been around 70 commits since
then.
Every colour-related modification referenced herein is always
implemented 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).
Such edits also account for colour-coding that is optimised for the
needs of users with red-green colour deficiency (deuteranopia or
variants).
Here is the URL of the manual: <https://protesilaos.com/emacs/modus-themes>.
Or read it from Emacs by evaluating this form:
(info "(modus-themes) Top")
The themes are built into Emacs version 28 (current development target),
and are available on GNU ELPA as well as other archives. This release
is the final one for the emacs-28 branch, as that gets cut as the next
stable release of GNU Emacs. Future releases will target Emacs 29 once
that becomes the new 'master' branch.
Customisation options
=====================
[ Themes need to be reloaded for changes to take effect. ]
+ Introduced the new 'modus-themes-tabs-accented' boolean option. When
set to non-nil, it renders the background of all tab interfaces in a
shade of blue. Those interfaces are tab-bar (built-in), tab-line
(built-in), and Centaur tabs.
- The background "accented" colour is the same as the one used for
mode lines when 'modus-themes-mode-line' is configured accordingly.
+ Tweaked the 'modus-themes-mode-line' to accept a 'padded' symbol as
part of the list of properties it can read. This will increase the
spacing around the mode lines' text, making the line taller overall
but also more spacious.
Thanks to Manuel Uberti for making the proposal and providing feedback
in issue 228: <https://gitlab.com/protesilaos/modus-themes/-/issues/228>.
+ Added the 'modus-themes-scale-small' which complements the existing
scale values with one that is meant to be smaller than the base
height. This option is reserved for special cases and is currently
only used as an opt-in feature in the Org agenda.
+ Expanded the 'modus-themes-org-agenda' with more parameters:
- The current date can now also be underlined.
- Date headings can be scaled/enlarged in size.
- Events, like those of the Diary or sexp entries, can be customised.
Consult the manual or the variable's doc string for the details.
+ Removed the obsoleted aliases 'modus-themes-slanted-constructs' and
'modus-themes-scale-5'. Those are superseded by the more
appropriately named 'modus-themes-italic-constructs' and
'modus-themes-scale-title'.
Thanks to Nicolas De Jaeghere for the patch in merge request 47:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/47>.
Faces and face groups
=====================
+ Make the 'prodigy' faces for red/green/yellow inherit from the faces
'error'/'success'/'warning', respectively. This is done to (i) avoid
duplication and (ii) ensure that the green/success colour coding is
consistent with the goal of the themes to empower users with red-green
colour deficiency. The boolean option that changes all such greens to
shades of blue is 'modus-themes-success-deuteranopia'.
+ Assigned the ':extend' attribute to the 'org-code' face. This is
necessary when the Org source contains lines that start with a colon
sign. Those are interpreted as code blocks. For example:
: #+BEGIN_SRC emacs-lisp
: (defun in-interval (bounds el)
: (and (>= el (car bounds)) (<= el (cadr bounds))))
: #+END_SRC
With the ':extend' in place, the background stretches to the edge of
the window, thus giving those lines a uniform rectangular shape. For
inline uses of 'org-code', the background should remain limited to the
span of the text.
+ Broadened support for 'marginalia' faces in two phases.
- The first pertained to the file permissions that are shown when
completing against file paths. Their style is similar to what
'dired+' or the 'direfl' packages provide, however we have taken
care to optimise the interface for the purposes of completion
UIs---where things can look like Dired, we make them alike, but
where they must differ, we differentiate the designs accordingly.
There can be no compromises or arbitrary constraints.
Also read: <https://github.com/minad/marginalia/pull/91>.
- The second batch covered all sorts of extra classes that provide
granular control over the appearance of Marginalia instances.
Refinements also had to be made to already-supported faces for the
sake of achieving consistency across the various Marginalia
interfaces.
Also read: <https://github.com/minad/marginalia/pull/92>.
+ Refined 'diredfl' and 'dired+' faces. For the various "priv" faces,
the intent is to increase the difference in hueness between adjacent
file permissions (the changes are minor, but they do change the
overall result). Numbers are toned down so that they do not clash
with dates. The file suffix no longer uses cyan to stand out more in
detailed views.
+ Made 'icomplete-selected-match' (Emacs28) more legible by aligning its
presentation with metaphors that are estaslished across the
modus-themes. Thanks to Kévin Le Gouguec (peniblec) for noting the
inconsistency with the new face upstream and for writing the patch for
it in merge request 50:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/50>.
Also thanks to Manuel Uberti for confirming that things would look
consistent in the comments' section of that merge request.
+ Fixed faulty inheritance for the 'web-mode-keyword-face'. It should
now properly copy the attributes of 'font-lock-keyword-face'.
+ Made inheritance of the new 'help-key-binding' (Emacs28 key) the
default for all faces that need to style key bindings.
In Emacs 28 all key bindings are automatically displayed with the face
'help-key-binding' which uses some new face attributes to draw a
cleaner box around it. Given that the themes must work with earlier
versions of Emacs, we cannot inherit it unconditionally so we added
the relevant conditionality. It is nice to offer this feature to
those who use the themes on Emacs 28. Older versions retain the
previous style of a blue colour coupled with a bold weight.
The exception to this rule is the transient.el faces (this is the
pop-up window used by Magit, among others---transient.el is now built
into Emacs). The box effect creates unpredictable misalignments, so
we default to the old key binding style for those.
Thanks to Manuel Uberti and Kevin Fleming for their feedback in issue
232: <https://gitlab.com/protesilaos/modus-themes/-/issues/232>.
+ Added support for the new 'notmuch-jump-key' face. I contributed this
face in commits c37c9912, 5cc106b0 to the Notmuch git repo:
<https://git.notmuchmail.org/git/notmuch>.
+ Updated the 'bookmark-face' (Emacs28) as it has been changed upstream
to be a fringe indicator instead of an in-buffer, line-wide background
highlight.
+ Aligned Ediff faces with other 'modus-themes-diffs' styles. Before we
would differentiate a "focus state", though that is now considered
surplus to requirements. The notion of a "focus state" only make
sense in Magit which applies variegated colour-coding to diff hunks
based on their state. Whereas non-active Ediff changes are grayed
out, so there is no need for further colour-coding nuances. The most
noticeable change is with:
(setq modus-themes-diffs 'bg-only)
As noted in the commit message of 64c74ae (from 2021-09-04):
If users think this change is for the worse, we can always define a
helper function like this:
(defun modus-themes--ediff-style (bgonly default)
"Diff style for Ediff.
BGONLY and DEFAULT depend on the value of `modus-themes-diffs'.
The former is more subtle."
(if (eq modus-themes-diffs 'bg-only)
(list bgonly)
(list default)))
And apply it thus:
`(ediff-current-diff-A ((,class :inherit ,@(modus-themes--ediff-style
'modus-themes-diff-removed
'modus-themes-diff-focus-removed))))
No feedback was received towards that end in about a month, so we
consider the change to be acceptable, without prejudice to the
possibility of future updates.
+ Unified the styles of 'org-agenda-calendar-sexp', 'org-agenda-diary',
and 'org-agenda-calendar-event'. This is not a user-facing change but
an internal refactoring to avoid repetition. It also makes things
easier for the implementation of the 'modus-themes-org-agenda' (as
mentioned above).
+ Ensured that the 'bookmark-menu-bookmark' face inherits from the
'bold' face. By default it hardcodes the bold weight, whereas we
instruct it to inherit the 'bold' face. A user can thus change the
':weight' of that face to whatever they want, like semibold,
extrabold, etc. We do this throughout the themes for bold and
italics---consider it a "hidden feature" of sorts. Check the manual
for more on the matter:
(info "(modus-themes) Configure bold and italic faces (DIY)")
+ Provided support for tab-bar groups (Emacs28). Specifically the faces
'tab-bar-tab-group-current' and 'tab-bar-tab-group-inactive'.
Thanks to Adam Porter (alphapapa) for the feedback in issue 8 over at
the Github mirror: <https://github.com/protesilaos/modus-themes/issues/8>.
+ Decoupled the 'stripes' face from that of 'hl-line-face'. This is
because the stripes are not meant to change depending on the value of
the user option 'modus-themes-hl-line'.
+ Revised the red shade of "flagged" entries in mu4e and notmuch. Those
are now consistent with Gnus. The shade of red that was used before
was closer to the orange side of the spectrum whereas the current has
hints of blue (a cherry colour) and thus combines better with the cyan
and blue that prevail in those interfaces. These are fine margins,
though the effect is noticeable regardless.
+ Configured the new 'ansi-color' faces (Emacs28) which are used by
shells and terminals (among others). Thanks to Manuel Uberti for
reporting the changes to upstream Emacs in issue 236:
<https://gitlab.com/protesilaos/modus-themes/-/issues/236>.
+ Expanded support for EMMS faces, pertaining to its browser views.
Thanks to Feng Shu (tumashu) for bringing those to my attention in
issue 11 over at the Github mirror:
<https://github.com/protesilaos/modus-themes/issues/11>.
+ Styled the new 'tab-line-tab-modified' face (Emacs28). It should now
use a faint red colour to denote changes to the underlying file.
Thanks to Adam Porter (alphapapa) for bringing it to my attention in
issue 12 over at the Github mirror:
<https://github.com/protesilaos/modus-themes/issues/12>.
+ Configured the single face that the 'cursor-flash' package has to
offer. Thanks to Manuel Uberti for the feedback in issue 231:
<https://gitlab.com/protesilaos/modus-themes/-/issues/231>.
+ Included 'elpher' in the list of supported packages by means of
covering the heading faces it implements.
+ Recalibrated certain dedicated colours for inactive tabs and tweaked
tab faces to (i) marginally improve the default aesthetic and (ii)
harmonise it with the style of 'modus-themes-tabs-accented'.
+ Removed the foreground attribute from all markup faces that are meant
to denote emphasis in italics. That is because such faces are
typically composed with others, so we do not wish to inadvertently
override any other colour that would otherwise have taken effect.
+ Wrote the faces for upstream Org that improve the contextuality of
various agenda views (included in version 9.5). This was done in
close collaboration with Gustavo Barros who offered detailed feedback
in issue 208 (which also led to the creation and eventual expansion of
the 'modus-themes-org-agenda' user option):
<https://gitlab.com/protesilaos/modus-themes/-/issues/208>.
Four new faces improve certain styles and offer more flexibility for
some Org agenda views: 'org-agenda-date-weekend-today',
'org-imminent-deadline', 'org-agenda-structure-secondary',
'org-agenda-structure-filter'. They inherit from existing faces in
order to remain backward-compatible.
Quoting from <https://list.orgmode.org/87lf7q7gpq.fsf@protesilaos.com/>:
+ The 'org-imminent-deadline' is useful to disambiguate generic
warnings from deadlines. For example, a warning could be
rendered in a yellow colored text and have a bold weight,
whereas a deadline might be red and styled with italics.
+ The 'org-agenda-structure-filter' applies to all tag/term
filters in agenda views that search for keywords or patterns.
It is designed to inherit from 'org-agenda-structure' in
addition to the 'org-warning' face that was present before (and
removes the generic 'warning' face from one place). This offers
the benefit of consistency, as, say, an increase in font height
or a change in font family in 'org-agenda-structure' will
propagate to the filter as well. The whole header line thus
looks part of a singular design.
+ The 'org-agenda-structure-secondary' complements the above for
those same views where a description follows the header. For
instance, the tags view provides information to "Press N r" to
filter by a numbered tag. Themes/users may prefer to
disambiguate this line from the header above it, such as by
using a less intense color or by reducing its height relative to
the 'org-agenda-structure'.
+ The 'org-agenda-date-weekend-today' provides the option to
differentiate the current date on a weekend from the current
date on weekdays.
Other patches I have made to, inter alia, emacs.git and org.git with
regard to faces are documented in previous change log entries.
Documentation
=============
+ Removed references to old versions of the themes from before their
refactoring in version 1.0.0. Those old packages no longer exist.
Users must install the 'modus-themes' and then load either of
'modus-operandi' or 'modus-vivendi'.
+ Included various extensions of the Vertico package in the list of
indirectly supported packages. Those define faces which either
inherit from basic ones that we already support or use colours that
are consistent with our accessibility target.
+ Referenced 'side-hustle', 'tide', 'bufler' as an indirectly supported
packages for the same reasons.
+ Simplified time-stamp local variables that are used in modus-themes.el
to show the time the file was edited. We apply 'time-stamp-pattern'
instead of setting multiple time-stamp variables. Thanks to Stephen
Gildea for the patch, which was sent to me via email (yes, you can
always do that).
+ Updated the manual's "acknowledgements" section to name all new
contributors to code/ideas/feedback.
+ Furnished information on how to configure the 'highlight-parentheses'
package and extend its faces for use with the themes. The entry
provides a complete Elisp implementation.
+ Improved the code samples for the prism.el setup that users may wish
to set up by themselves. The new lists of colours work better when
Prism's colouration is limited to a small set of hues.
+ Deleted trailing whitespace in the manual which had adverse effects
when trying to compile the modus-themes.org over at emacs.git. Thanks
to Philip Kaludercic for the patch in merge request 49:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/49>.
Thanks again to everyone involved. Looking forward to see the Modus
themes, version 1.6.0, as part of the next stable release of Emacs.
#+end_src
* 1.5.0
:PROPERTIES:
:CUSTOM_ID: h:05fc633d-69d6-4b5e-aade-1f9e4ba30ed3
:END:
#+begin_src text
Modus themes version 1.5.0
By Protesilaos Stavrou <info@protesilaos.com> on 2021-07-15
This entry outlines the set of changes made to the project since the
release of version 1.4.0 on 2021-05-25. There have been over 130
commits since then.
Every colour-related modification referenced herein is always
implemented 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).
Such edits also account for colour-coding that is optimised for the
needs of users with red-green colour deficiency (deuteranopia or
variants).
Here is the URL of the manual: <https://protesilaos.com/emacs/modus-themes>.
Or read it from Emacs by evaluating this form:
(info "(modus-themes) Top")
The themes are built into Emacs version 28 (current development target),
and are available on GNU ELPA as well as other archives.
Customisation options
=====================
Overview of new style of sets of properties
-------------------------------------------
Several variables now accept a list of symbols as a value. Those
represent properties, which can be combined with each other to realise
the possible styles. The idea was to simplify their specification in
order to make them easier to both maintain and extend. Thanks to Philip
Kaludercic for introducing this concept in issue 210:
<https://gitlab.com/protesilaos/modus-themes/-/issues/210>.
The variables are:
+ 'modus-themes-prompts' by Philip Kaludercic in merge request 43:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/43>
+ 'modus-themes-mode-line' by Philip Kaludercic in merge request 40:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/40>.
+ 'modus-themes-lang-checkers' by Philip Kaludercic in merge request 46:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/46>
+ 'modus-themes-org-agenda'
+ 'modus-themes-links'
+ 'modus-themes-headings'
+ 'modus-themes-hl-line'
+ 'modus-themes-paren-match'
+ 'modus-themes-region'
+ 'modus-themes-syntax'
Take 'modus-themes-syntax' as an example. Up until version 1.4.0, it
would only accept a symbol, signifying a predefined style. So we had
the possible value 'faint' and another 'faint-yellow-comments'. To make
a third variant of the "faint" aesthetic, such as by combining it with
the "alt syntax" and/or "green strings", we would need to write new
presets in the form of 'faint-green-strings', 'faint-alt-syntax',
'faint-alt-syntax-green-strings', 'faint-green-strings-yellow-comments',
'faint-alt-syntax-green-strings-yellow-comments'. That would have been
inefficient, hence why it was not done.
With the new approach of defining a list of properties, those
combinations are all possible. Such as:
(setq modus-themes-syntax '(faint alt-syntax))
(setq modus-themes-syntax '(yellow-comments alt-syntax green-strings))
The order in which the properties are set is not significant.
The doc string of each of the aforementioned variables, or the
corresponding entry in the manual, provides guidance on how to configure
things. The old forms will continue to work for the time being, though
they are considered deprecated and will stop being supported at a future
date.
Changes in stylistic variants for variables with sets of properties
-------------------------------------------------------------------
+ The meaning of the "alt syntax" style in 'modus-themes-syntax' has
been redefined. In the past, it used to have green-coloured strings
and doc strings. Those are now red. Some other changes have been
implemented to make the overall looks more consistent. Users who
liked the old style can retain it by passing this list of properties:
(alt-syntax green-strings)
New styles for the "faint" aesthetic are possible, here shown as lists
of properties:
(faint green-strings)
(faint alt-syntax)
(faint alt-syntax green-strings)
To each of those the 'yellow-comments' property can be added as well.
Consult the doc string or the manual for the technicalities and code
samples.
+ The 'modus-themes-hl-line' no longer has styles that include only an
underline. Those proved to be problematic under certain circumstances
and were thus removed.
Minor changes have been implemented to make the following combination
of properties more consistent, by colourising the underline:
(accented intense underline)
+ The 'modus-themes-paren-match' now has styles that include an
'underline' property. Those extend the old options, such as:
(bold intense underline)
+ The 'modus-themes-headings' have an improved set of styles for the "no
text color" aesthetic. Those involve the 'monochrome' property, which
can now yield results that include a background (whereas before it was
just colourless text for the headings, optionally without a bold
weight). As this is an alist, here is an example (always check the
docs for fully fledged code samples):
(setq modus-themes-headings
'((1 . (background overline))
(2 . (overline background rainbow))
(t . (monochrome no-bold background))))
To allow a heading level N to retain its original style, a 't' value
can be passed. In the previous version of the themes, it was possible
to use 'nil' for the same purpose, though that is no longer valid. In
those cases, the fallback value of the alist will be used instead,
such as what is noted above:
(t . (monochrome no-bold background))
+ The 'modus-themes-links' provide several new possible styles, due to
an expanded set of properties that includes, among others, 'bold',
'italic', and 'background'. The documentation covers the details.
+ The 'modus-themes-lang-checkers' can now attain a style that uses a
prominently coloured background in addition to what was available
before as a subtle background and the other variants.
New variables
-------------
+ The 'modus-themes-org-agenda' provides the means to refashion the
entirety of the Org agenda buffer. The value it accepts is an alist,
with some keys expecting a symbol and others a list of properties.
The minutia are covered in its doc string. A possible configuration
can look like this:
(setq modus-themes-org-agenda
'((header-block . (variable-pitch scale-title))
(header-date . (grayscale workaholic bold-today))
(scheduled . uniform)
(habit . traffic-light)))
'modus-themes-org-agenda' supersedes the old variable that was specific
to the Org habit graph: 'modus-themes-org-habit'. There now is a
'habit' key which accepts the same values as before, plus a new style
that is optimised for users with red-green colour deficiency:
'traffic-light-deuteranopia'. Please consult the doc string of
'modus-themes-org-agenda' or the relevant entry to the manual.
Thanks to Gustavo Barros for contributing to the creation of this
variable as well as to all other changes in the relevant faces that
were done in the interest of usability. A full report about
'modus-themes-org-agenda' with screen shots is available here:
<https://protesilaos.com/codelog/2021-06-02-modus-themes-org-agenda/>.
A patch has been sent to upstream Org, with its review pending, which
improves upon some of the areas we had identified:
<https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00092.html>.
+ The 'modus-themes-inhibit-reload' controls a new behaviour of
automatically reloading the active theme when an option is set via the
Custom interfaces or with 'customize-set-variable'. To opt-in to this
feature, set the variable to a 'nil' value.
Thanks to Philip Kaludercic for implementing this in merge request 40:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/40>.
In the development phase of this option, a bug was identified
pertaining to recursion, as reported by Gustavo Barros in issue 213:
<https://gitlab.com/protesilaos/modus-themes/-/issues/213>. Changes
have been made to remove that possibility, as found in merge request
45: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/45>.
A thread was started on the emacs-devel mailing list to inquire upon
the technicalities of this option, but it did not gain any traction:
<https://lists.gnu.org/archive/html/emacs-devel/2021-06/msg00828.html>.
As such, we have decided to take our chances by pressing on with this
feature. Users who are interested in it are encouraged to give it a
try and report any possible complications. Issue 213 remains open.
+ The 'modus-themes-italic-constructs' is the new name of the variable
'modus-themes-slanted-constructs'. The term "slant" was considered
too vague or technical and some users could have missed the meaning of
this option.
+ The 'modus-themes-scale-5' is renamed to 'modus-themes-scale-title' to
better convey its utility.
Changes to the manual
=====================
+ Rewrote or introduced the documentation for all the customisation
options mentioned above. Also updated relevant code samples, such as
in the manual's introduction to the customisation options. Evaluate
this form for an annotated code overview:
(info "(modus-themes) Customization Options")
+ Rephrased a reference to "gamma ray values" as "gamma values". Thanks
to Anders Johansson for the contribution in merge request 42:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/42>.
+ Removed the Org macro that would insert the build date in the manual's
introduction. This was required to make the file reproducible,
otherwise it would keep changing each time a new version of Emacs was
built. Refer to Emacs bug#48661 by Glenn Morris:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48661>.
+ Included note on tweaking the key hints that the Avy package produces.
This is in response to issue 215 by Rudolf Adamkovič:
<https://gitlab.com/protesilaos/modus-themes/-/issues/215>. Thanks to
Nicolas De Jaeghere for providing the text.
+ Wrote a note on how to control the underlines that are generated in
compilation-mode buffers and related. It is about configuring the
variable 'compilation-message-face'.
+ Documented how to configure the colours that are applied to the names
of the days in the 'M-x calendar' interface. The relevant variable is
'calendar-weekend-days'.
+ Elaborated on a "do it yourself" (DIY) guide on how to benefit from
the hidden feature of the themes about how they handle the bold weight
and the italic slant. In short, we do not hardcode values and thus
make it easy for users to specify the particularities of what it means
for a face to have a 'bold' or 'italic' attribute.
Faces and face groups
=====================
New entries
-----------
Newly supported packages:
+ 'ledger-mode'. Thanks to Pengji Zhang for the feedback in issue 202:
<https://gitlab.com/protesilaos/modus-themes/-/issues/202>.
+ 'gotest'. Thanks to Jerry Zhang for the feedback in issue 226:
<https://gitlab.com/protesilaos/modus-themes/-/issues/226>.
+ 'css-mode'
New faces for already supported groups:
+ 'shr-h1', 'shr-h2', 'shr-h3', 'shr-h4', 'shr-h5', 'shr-h6' of the
shr.el library (simple HTML renderer, as experienced in, for example,
EWW). Those are available for Emacs28, with a patch by me:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=49433>
+ 'apropos-button' as a generic face that fontifies faces in apropos
buffers. Available for Emacs28, with a patch by me:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49162>.
+ 'selectrum-mouse-highlight'. This makes the mouse hover effect for
selectrum look the same as in most other contexts. Thanks to okamsn
for the feedback in issue 203:
<https://gitlab.com/protesilaos/modus-themes/-/issues/203>.
Review of existing entries
--------------------------
+ Added an ':extend' property to 'next-error' face. This face is used
for pulse effects. It is good to have them extend to the edge of the
window, so that they are easier to spot. Thanks to Gustavo Barros for
the feedback in issue 200, which is about pulse.el:
<https://gitlab.com/protesilaos/modus-themes/-/issues/200>.
+ Tweaked the various Apropos faces. The idea was to remove the colour
from the pseudo headings so that we would not get an exaggerated
result of too much variety in the buffer (e.g. that of 'M-x apropos').
The individual buttons retain their style as links, meaning that they
are governed by the variable 'modus-themes-links'.
+ Revised 'whitespace-line' face to make it look like a warning, as it
ought to be. Thanks to Pengji Zhang for the feedback in issue 204:
<https://gitlab.com/protesilaos/modus-themes/-/issues/204>.
+ Reworked the colour-coding of the Hydra and Transient packages. These
are meant to tone down some excesses with the standard red and to
adapt other colours to it. Thanks to Gustavo Barros for providing
suggestions and helping me tweak those in issue 206:
<https://gitlab.com/protesilaos/modus-themes/-/issues/206>.
+ Recoloured 'transient-argument' to improve its uniqueness in its
context and to better comply with the expectation of hydra-style
colour coding, as noted right above.
+ Made the 'org-agenda-done' face conform with the customisation option
'modus-themes-success-deuteranopia'. This means that it will be
coloured in blue instead of green when the option is set to a non-nil
value.
+ Grayed out the foreground of the Org block delimiter lines on the
premise that any extra colouration was not needed, given the presence
of a gray background and the overall markup of the block.
+ Toned down the colouration of the 'org-code' face, so that it is
consistent with 'org-verbatim' as well as the colours used in opening
and closing lines of blocks. Thanks to Gustavo Barros for suggesting
this change in issue 206, though it went through a couple of reviews:
<https://gitlab.com/protesilaos/modus-themes/-/issues/206>.
+ Simplified the inheritance of the 'fixed-pitch' face, which is used
for internal purposes to ensure alignment of elements in buffers that
must cope with mixed font configurations, such as an org-mode file
with 'M-x variable-pitch-font' enabled.
[ Recall that the option 'modus-themes-no-mixed-fonts' can disable
this feature. Also note that the 'mixed-fonts' package, or
equivalent, is not needed while using the Modus themes (though there
is nothing wrong with having them together). ]
+ Reduced the overall intensity of 'org-mode-line-clock-overrun'.
Thanks to Gustavo Barros for the feedback in issue 208:
<https://gitlab.com/protesilaos/modus-themes/-/issues/208>.
+ Simplified or otherwise tweaked several Org agenda faces to render
possible the new 'modus-themes-org-agenda' variable, as documented
above. Thanks to Gustavo Barros for the feedback in issue 208:
<https://gitlab.com/protesilaos/modus-themes/-/issues/208>.
+ Increased ever so slightly the foreground colour of the 'highlight'
face. This can help improve the perception of highlights, such as
upon hovering over a link with the mouse. Thanks to Rudolf Adamkovič
for reporting the potential problem in issue 216:
<https://gitlab.com/protesilaos/modus-themes/-/issues/216>.
+ Prevented the override of the 'diff-context' face when users assign a
'bg-only' value to the 'modus-themes-diffs' variable. This makes it
consistent with the intent of this style, which is to work with a
non-nil value for 'diff-font-lock-syntax' (basically to allow the
usual colour highlights of the underlying code syntax in diff
buffers).
+ Ensured consistency of all prompt-related faces by introducing a new
face, 'modus-themes-prompt', that is inherited by all others (all
prompt styles are controlled by the variable 'modus-themes-prompts').
This was originally implemented with the 'comint-highlight-prompt'
face, though that could potentially lead to undefined faces if the
comint library was not loaded. Whereas the 'modus-themes-prompt'
guarantees that we pass a known face at all times. Thanks to Philip
Kaludercic for bringing this potential bug to my attention in a
comment to merge request 43:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/43#note_615224855>.
+ Removed the background colour from the 'widget-inactive' face. It
would create problems in some cases, such as in Custom buffers for
multiple choice options.
+ Refined 'calendar-weekend-header' and 'calendar-weekday-header' to
emulate the design of physical calendars and remain truthful to the
expectations set by the default configuration of the calendar.el
library. Weekends now use a faint red, while weekdays are rendered in
the same subtle gray they had before. The underlying principle is to
make weekends convey a subtle warning to the effect that "this is not
a day for work" (notwithstanding precarious economic realities). As
noted above, there is an entry in the manual on how to make all days
look the same, be it gray or faint red. Evaluate this form:
(info "(modus-themes) Note on calendarel weekday and weekend colors")
Request for feedback on a potential version 2.0.0 of the Modus themes
=====================================================================
While we maintain a cautious stance towards preserving the default
styles, there are some cases where we might be forced to introduce
backward-incompatible changes.
Three such cases that can benefit from user feedback are:
+ Issue 196 on 'modus-themes-no-mixed-fonts'
<https://gitlab.com/protesilaos/modus-themes/-/issues/196>.
+ Issue 198 on 'modus-themes-hl-line'
<https://gitlab.com/protesilaos/modus-themes/-/issues/198>
[ Note that 'modus-themes-hl-line now accepts a list of properties as
described in the opening sections of this entry. ]
+ Issue 218 on 'modus-themes-diffs'
<https://gitlab.com/protesilaos/modus-themes/-/issues/218>.
Miscellaneous
=============
+ Recalibrated the value of the colour 'bg-hl-line-intense' in the
palette 'modus-themes-vivendi-colors'. The change should be
practically indecipherable, though it slightly improves things in
certain contexts.
+ Refined the intensity of the three main yellow colours in
'modus-themes-vivendi-colors'.
+ Introduced a new 'modus-themes-faces' group so that those are
decoupled from the customisation options in the various Custom
buffers. Thanks to Philip Kaludercic for the patch in merge request
39: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/39>.
+ Updated the manual's "Acknowledgements" section to include all new
users who contributed to the project.
Thanks again to everyone involved!
#+end_src
* 1.4.0
:PROPERTIES:
:CUSTOM_ID: h:4c643e3c-5284-4fab-97e8-217bc1c02f5d
:END:
#+begin_src text
Modus themes version 1.4.0
By Protesilaos Stavrou <info@protesilaos.com> on 2021-05-25
This entry records the changes made to the project since the release of
version 1.3.0 on 2021-04-17. There have been around 100 commits in the
meantime, as is the norm.
If you are coming from older versions, please consult the change log
entry for version 1.0.0 with regard to the breaking changes that were
introduced.
Every colour-related modification is always done in accordance with the
overarching 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).
URL of the official manual: <https://protesilaos.com/emacs/modus-themes>. Or
read it with Emacs' Info reader by evaluating this form:
(info "(modus-themes) Top")
Remember that the themes are built into Emacs version 28 (current
development target), and are available on GNU ELPA, as well as other
archives.
Customisations variables
------------------------
+ Redefined the style of 'fg-only' that 'modus-themes-diffs' accepts, so
that it no longer uses a red-green colour coding, but applies a
red-blue distinction instead. The symbol 'fg-only' is a deprecated
alias for the more descriptive 'fg-only-deuteranopia'.
This is done because green text on a light background is one of the
worst combinations for the purposes of legibility, as it does not
stand out in its context and thus forces undesirable compromises.
Whereas red and blue work well in this case, while making the style
accessible to users with red-green colour deficiency (deuteranopia).
To avoid inconsistencies between Modus Operandi and Modus Vivendi, we
replace green with blue in both themes. A full report is available in
issue 183 which was created on April 21, 2021:
<https://gitlab.com/protesilaos/modus-themes/-/issues/183>.
+ Introduced the boolean 'modus-themes-success-deuteranopia' which
replaces all instances of green with blue in contexts where a
red-green colour coding is in effect (e.g. Org TODO vs DONE keywords,
isearch current match...).
+ Implemented 'modus-themes-mail-citations' to control the colouration
of cited text in email-related buffers, such as Gnus or message.el.
It accepts values nil, 'faint', and 'monochrome'. By default (the nil
value) the text of citations cycles through blue, green, red, yellow
depending on the level of depth.
+ Expanded the set of options for 'modus-themes-mode-line' to encompass
the values 'borderless-accented', 'borderless-accented-3d', and
'borderless-accented-moody'. Those are variations of existing styles.
The complete list:
- nil (default)
- 3d
- moody
- borderless
- borderless-3d
- borderless-moody
- accented
- accented-3d
- accented-moody
- borderless-accented
- borderless-accented-3d
- borderless-accented-moody
+ Renamed the non-nil values that 'modus-themes-org-blocks' accepts from
'grayscale', 'rainbow' to 'gray-background' and 'tinted-background',
respectively. The new symbols better describe their effect on Org
source blocks, namely, that they affect the background of the block
rather than the foreground. The old symbols will still work but are
considered deprecated aliases of the newer ones.
+ Altered the intensity of the 'modus-themes-hl-line' option
'accented-background' to a more noticeable shade of cyan/teal. The
old style was too subtle to have the desired effect. The value
'underline-accented' is not affected by this change, as it still uses
the same subtle background it did before in combination with a more
pronounced underline colour.
+ Deleted all deprecation warnings that concerned the transition from
version 0.13.0 of the themes to 1.0.0. Those had been in effect for
several months, spanning four tagged releases.
Faces or face groups
--------------------
+ Reconsidered the use of colour in all email-related citation faces to
avoid exaggerations and reduce complexity. Colour values have been
tweaked to tone down their overall intensity, while the number of
colours has been reduced to four. Gnus and Mu4e have faces for more
levels of citation depth, though those will simply repeat the
four-colour cycle.
+ Made the 'message-mml' face look consistent with the rest of the
buffer while composing an email by changing its foreground colour from
a yellow to a cyan variant.
+ Refined several faces in the Notmuch group in the interest of harmony:
- Individual message headers in 'notmuch-show-mode' use bold text in
addition to their existing subtle background to better stand out in
their context. The face is 'notmuch-message-summary-face'.
- Tags are no longer set unconditionally to a bold typographic weight.
They become such for unread threads in 'notmuch-search-mode'
buffers, as well as for headers of 'notmuch-show-mode'.
- Removal and addition of tags is now denoted by a strike-through and
an underline effect, respectively, whereas before they both used
underlines with the only difference being their colour.
- The subject line in 'notmuch-search-mode' buffers uses the main
foreground instead of a dimmed one. The field of matching authors
has a tweaked foreground to keep the tabular view easy to read.
- All cryptography-related faces are simplified to not show a coloured
background but only use a foreground colour instead.
+ Removed direct support for 'counsel-notmuch' as it already inherits
from the relevant notmuch faces. The package is thus considered
indirectly supported.
+ Refrained from setting a background to the 'csv-separator-face' as it
would inevitably colourise the negative space in the tabular view
created by 'csv-align-mode'. A red text colour is used instead, even
though this is not common practice: it is easier to spot for small,
single characters, such as a comma or a semicolon that is meant to
have a special meaning. Thanks to Kevin Fleming for reporting the
problem and for offering feedback on the choice of colour in issue
194: <https://gitlab.com/protesilaos/modus-themes/-/issues/194>.
+ Distinguished between ordinary links and widget buttons by removing
the underline from the latter (the 'widget-button' face) and altering
the shade of its foreground colour. Such widgets are used in Emacs'
Custom interfaces and can also be found in the default Notmuch "hello"
buffer that runs 'notmuch-hello-mode'.
+ Tweaked the Ediff current faces to be consistent with 'diff-mode' and
related. In practice, this only applies when 'modus-themes-diffs' is
set to a value of 'fg-only-deuteranopia', as it adds a dim background
to the current diff hunk. All other styles of 'modus-themes-diffs'
look the same as before while using Ediff.
+ Simplified the faces of 'corfu' to match the current state of the
upstream project. Thanks to Daniel Mendler (its developer) for
reporting this in issue 184:
<https://gitlab.com/protesilaos/modus-themes/-/issues/184>.
+ Refined all Eshell faces so that the output of 'ls' is consistent with
the overall aesthetic of the themes. Also made 'eshell-prompt'
inherit from 'comint-highlight-prompt' to look the same as other such
prompts (all are configurable by 'modus-themes-prompts').
+ Revised 'eshell-prompt-extras' and 'eshell-git-prompt' to use colours
and typographic weight that better match the style of the various
configurations they offer.
+ Simplified 'eshell-syntax-highlighting' to inherit from the standard
Eshell faces, where appropriate.
+ Adjusted the colour of 'centaur-tabs-active-bar-face' and removed the
bespoke 'fg-tab-accent' colour from 'modus-themes-operandi-colors' and
'modus-themes-vivendi-colors' that was only used by it (and which
should have never been introduced to begin with).
+ Updated the 'tab-bar-groups' faces to match changes upstream. Thanks
to Fritz Grabo (its developer) for the patch in merge request 35:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/35>.
+ Changed the Ibuffer title and group faces to better differentiate
between group titles and special or non-file-visiting buffers. Thanks
to Nicolas De Jaeghere for the patch in merge request 37:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/37>.
+ Ensured that all faces that denote a "success" state, or which are
expected to be coloured in green in a red-green binary, can use an
appropriate blue colour (or colour combination that involves blue)
instead when 'modus-themes-success-deuteranopia' is set to a non-nil
value.
+ Added support for the new 'bookmark-face' in Emacs version 28. This
means that the built-in bookmark.el library is directly supported by
the themes. This face can be disabled by setting 'bookmark-fontify'
to nil. Thanks to Mark Barton for reporting the presence of this new
face and for providing feedback on its style in issue 189:
<https://gitlab.com/protesilaos/modus-themes/-/issues/189>.
+ Aligned 'hes-mode' ('highlight-escape-sequences') with the standard
font-lock faces for regexp grouping. This means that it conforms with
changes to the 'modus-themes-syntax' variable.
+ Reconfigured the 'org-quote' face to adapt its style depending on the
value of 'modus-themes-org-blocks'. The default is a subtle blue/cold
foreground colour against the main background. When a value of
'gray-background' is assigned to 'modus-themes-org-blocks', the text's
colour becomes that of the main foreground in order to maintain a good
level of legibility. Thanks to Rudolf Adamkovič for the feedback in
issue 190: <https://gitlab.com/protesilaos/modus-themes/-/issues/190>.
+ Refashioned the 'show-paren-match-expression' face to make it apply a
bespoke background colour and not override the expression's foreground
colours. This face is used by 'show-paren-mode' when the
customisation variable 'show-paren-style' is set to the 'expression'
value. Thanks to Rudolf Adamkovič for the feedback in issue 191:
<https://gitlab.com/protesilaos/modus-themes/-/issues/191>.
+ Made headings level 8 use a fine shade of magenta by default instead
of gray (notwithstanding user changes to 'modus-themes-headings').
This should have a negligible difference in Org or Outline buffers,
but is more noticeable when editing Elisp in Emacs28 while also using
'outline-minor-mode' and with 'outline-minor-mode-highlight' set to
'override'. That is because several top-level forms use that heading
level with those configurations.
Documentation (the manual)
--------------------------
+ Incorporated a sample configuration block with all customisation
variables and with comment annotations of their available options, in
an attempt to make it easier for users to discover what the themes
provide.
+ Replaced all instances of "modeline" with "mode line" for consistency
with the Emacs style. Thanks to Rudolf Adamkovič for the patch that
started this process in merge request 33:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/33>.
+ Wrote note on setting mode line faces that indicate the state of
'god-mode'. Thanks to Rudolf Adamkovič for the feedback in issue 187:
<https://gitlab.com/protesilaos/modus-themes/-/issues/187>. Also
thanks to Rudolf for updating the applicable hook in merge request 34:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/34>.
+ Listed 'org-mode' variables that affect fontification in blocks:
'org-src-fontify-natively', 'org-fontify-whole-block-delimiter-line',
and 'org-fontify-quote-and-verse-blocks'. This complements the
already documented variables 'org-fontify-whole-heading-line' and
'org-fontify-done-headline' that pertain to headings.
+ Included note on fontifying inline Latex expressions in Org buffers.
Thanks to Rudolf Adamkovič for the feedback in issue 190:
<https://gitlab.com/protesilaos/modus-themes/-/issues/190>.
+ Elaborated on the use of 'face-remap-add-relative' by means of sample
code that cycles through arbitrary colours for the 'region' face.
This is filed under the "Do It Yourself" (DIY) section.
+ Provided a DIY method for adapting the fontification of Org source
block delimiter lines to the value of 'modus-themes-org-blocks'.
+ Expanded the DIY entry on overriding the saturation of the active
theme's colours with a method that combines the programmatic approach
with manual overrides. The user can thus specify the colour values
they want to override and let the rest be handled by Elisp.
+ Introduced a section with answers to Frequently Asked Questions (FAQ)
about the design of the themes as well as recommendations on how to
ensure optimal reading conditions or start thinking about them. The
questions are:
- Is the contrast ratio about adjacent colors?
- What does it mean to avoid exaggerations?
- Why are colors mostly variants of blue, magenta, cyan?
- What is the best setup for legibility?
Miscellaneous
-------------
+ Removed superfluous code from internal functions and adapted their
indentation to make them easier to read.
+ Recalibrated some values in 'modus-themes-vivendi-colors' to ensure
consistency in luminance with other colours that are used in their
context. Those are subtle changes that can only be discerned in
side-by-side comparisons of the before and after states. Thanks to
André Alexandre Gomes for the feedback in issue 193:
<https://gitlab.com/protesilaos/modus-themes/-/issues/193>.
+ Changed the saturation and hueness of the bespoke 'fg-comment-yellow'
in 'modus-themes-operandi-colors' and 'modus-themes-vivendi-colors' to
better contrast with its context, while still keeping its luminance
consistent with its role as a colour for comments in code. This is
used when 'modus-themes-syntax' is configured appropriately (read its
doc string or consult the manual).
+ Attempted to add explicit support for the faces of the built-in
pulse.el library, but ultimately opted against them as the doc string
of 'pulse-highlight-face' advises against customising it, even though
it is not clear from the source code in emacs.git what the problem
could be. We shall reconsider this case for the next release cycle.
Thanks to Gustavo Barros for the feedback on several aspects of this
topic in issues 185 and 200:
- <https://gitlab.com/protesilaos/modus-themes/-/issues/185>
- <https://gitlab.com/protesilaos/modus-themes/-/issues/200>
+ Took the feedback of John Haman in issue 199 as a reminder to complete
the set of possible values for the 'modus-themes-mode-line' variable:
<https://gitlab.com/protesilaos/modus-themes/-/issues/199>.
#+end_src
* 1.3.0
:PROPERTIES:
:CUSTOM_ID: h:5063c0c5-832e-4577-936e-d602b07d6d79
:END:
#+begin_src text
Modus themes version 1.3.0
By Protesilaos Stavrou <info@protesilaos.com> on 2021-04-17
This entry records the changes introduced to the project since the
publication of version 1.2.0 (2021-03-04). There have been around 100
commits in the meantime, as is the norm with all releases hitherto.
Every colour-related modification documented 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
combination (the WCAG AAA standard).
As the official manual is referenced several times throughout this log,
make sure to store its URL: <https://protesilaos.com/emacs/modus-themes>. Or
read it from Emacs' Info reader by evaluating this form:
(info "(modus-themes) Top")
If you are coming from older versions, please consult the change log
entry for version 1.0.0 with regard to the breaking changes that were
introduced.
Remember that the themes are built into Emacs28, and are available on
GNU ELPA, as well as other archives.
Customisation options
---------------------
+ The old 'modus-themes-intense-hl-line' boolean variable has been
replaced by 'modus-themes-hl-line', which provides several options for
how to style the current line of 'hl-line-mode'. To retain the old
effect, one must do this:
;; Replacement for (setq modus-themes-intense-hl-line t)
(setq modus-themes-hl-line 'intense-background)
The list of possible values:
1. nil (default)
2. intense-background
3. accented-background
4. underline-neutral
5. underline-accented
6. underline-only-neutral
7. underline-only-accented
The doc string of 'modus-themes-hl-line' as well as the manual
describe the specifics. Thanks to Manuel Uberti for the feedback in
commit b020592:
<https://gitlab.com/protesilaos/modus-themes/-/commit/b020592e1a96d6e00d7d03faf9c293ec6081d49c>.
+ The 'modus-themes-mode-line' variable now accepts three new "accented"
styles that complement the existing set:
1. nil (default)
2. 3d
3. moody
4. borderless
5. borderless-3d
6. borderless-moody
7. accented
8. accented-3d
9. accented-moody
+ The 'modus-themes-region' is extended with two new options of an
"accent" background:
1. nil (default)
2. no-extend
3. bg-only
4. bg-only-no-extend
5. accent
6. accent-no-extend
+ The default value of 'modus-themes-headings' for per-level styles can
now be set to nil. This fixes an inconsistency between the fallback
value, which accepted nil, and the per-level styles which did not.
Thanks to Mauro Aranda for reporting this in issue 163:
<https://gitlab.com/protesilaos/modus-themes/-/issues/163>.
Please read the manual for the specifics of this variable, as it is an
alist that accepts several possible combinations.
Updates to the manual
---------------------
+ Rewrote the sections that cover the aforementioned customisation
options.
- For 'modus-themes-mode-line', we had to revise the recommendation
for setting 'face-near-same-color-threshold' to 45000. That value
is appropriate for the 'moody' and 'borderless-moody' options.
Whereas for 'accented-moody' the number should be raised to 70000.
Thanks to Nicolas De Jaeghere for providing this piece of
information:
<https://gitlab.com/protesilaos/modus-themes/-/commit/ab6ba698269f012ec880b690282264649bfb3b0d#note_551342198>
+ Rephrased the GNU Free Documentation License quote to match the style
of other manuals that are also built into Emacs.
+ Documented 'org-mode' variables that affect the looks of various
fontification styles.
+ Simplified the 'kbd' macro that is declared in modus-themes.org to
allow GNU ELPA's build system to parse the file for Emacs 26.
+ Documented existing support for 'tab-bar-mode' and 'tab-line-mode'.
+ Wrote a note on how to configure the 'dimmer.el' library by Neil
Okamoto, in order to guarantee consistent results with the themes.
The key is to use the RGB colour space instead of CIELAB.
+ Included note on shr.el fonts and how those are used by EWW and
Elfeed.
+ Added a "Do-It-Yourself" (DIY) section on how to remap buffer-local
faces.
+ Detailed a DIY method to make the buffer-local backdrop of a pdf-tools
page use a distinct colour than the default white for Modus Operandi.
Extended the same principle to Modus Vivendi and described how to
adapt to theme changes (such as via 'modus-themes-toggle'). Thanks to
Utkarsh Singh for providing feedback on this topic in issue 175:
<https://gitlab.com/protesilaos/modus-themes/-/issues/175>.
+ Elaborated on DIY techniques to programmatically override the
saturation of all colours specified by the active Modus theme. Thanks
to user pRot0ta1p for the feedback in issue 166:
<https://gitlab.com/protesilaos/modus-themes/-/issues/166>.
Support for packages
--------------------
These are added to the already comprehensive list of explicitly
supported packages:
+ corfu
+ embark
+ pandoc-mode. Thanks to Farasha Euker for the feedback in issue 171:
<https://gitlab.com/protesilaos/modus-themes/-/issues/171>.
+ tab-bar-groups
+ telega
+ vertico
Also added support for the 'help-key-binding' face which is part of
Emacs 28.
Changes to already supported faces or face groups
-------------------------------------------------
+ Renamed all internal faces that the themes defined from
"modus-theme-*" to "modus-themes-*".
+ Refashioned all Ediff faces in the process of a major review of this
tools' overall design. The manifold changes are:
- All inactive diffs respect the underlying fontification
(e.g. programming syntax highlighting). Before they would override
it with a gray foreground.
- All inactive diffs have been toned down, as their background is a
finer shade of gray than the prominent one that was used before.
- There no longer is a visual distinction between even and odd
inactive diffs (by means of different shades of gray). We are of
the opinion that such subtleties, whose utility is marginal at best,
have no place in themes that are designed for accessibility.
- All bespoke gray colour combinations that were only intended for
those inactive diffs have thus been removed from each theme's
palette.
- Active diffs follow the same style as diff-mode, to ensure
theme-wide consistency (all diff styles are controlled by the
variable 'modus-themes-diffs').
This topic was discussed at length (with screenshots) in issue 169:
<https://gitlab.com/protesilaos/modus-themes/-/issues/169>. Thanks to
peniblec and Nicolas De Jaeghere for their feedback.
+ Made 'smerge-markers' and 'vdiff-closed-fold-face' look like the
headings in 'diff-mode' in the interest of consistency, especially
while configuring the 'modus-themes-diffs' variable.
+ Ensured consistency between all faces that pertain to key bindings in
contexts where the hint to the key is active, in that pressing the key
performs the action (e.g. Magit's transient buffers, which-key,...).
The 'help-key-binding' for Emacs 28 is not included in this group,
because it applies in cases where the keys are not active, such as in
Help buffers.
+ Refined 'epa-validity-disabled' and 'epa-validity-high' faces. The
former no longer uses a background, as that was considered an
exaggeration. While the latter is cast in a cyan hue instead of green
for greater clarity (this relates to the general push to optimise for
red-green colour deficiency, which means to only use green where it is
absolutely necessary and, in such cases, to provide for a blue-ish
alternative, as with the 'deuteranopia' value that can be assigned to
'modus-themes-diffs').
+ Reworked 'ace-window', 'avy', and 'magit-blame' faces to ensure that
their overlays do not inherit the face properties of underlying text,
such as a different font family or height. Thanks to Nicolas De
Jaeghere for the multiple merge requests and the concomitant feedback:
- <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/27>.
- <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/29>.
- <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/30>.
- <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/31>.
- <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/32>.
Also thanks to Damien Cassou for reporting an intermediate problem
with 'avy' in issue 177; a problem that was eventually addressed by
Nicolas De Jaeghere in merge request 31 (cited above):
<https://gitlab.com/protesilaos/modus-themes/-/issues/177>.
+ Optimised the colour combinations used by 'avy' to improve the
distinction between consecutive characters.
+ Reduced the brightness of EWW certificate faces, as they would attract
disproportionate attention to themselves.
+ Reworked all EWW text field and button faces to look more like what
they are supposed to.
+ Removed the slant and distinct foreground from the 'org-quote' face,
as they would interfere with emphasis within the quote block. Thanks
to Farasha Euker for the feedback in issue 171:
<https://gitlab.com/protesilaos/modus-themes/-/issues/171>.
+ Reduced the intensity in colouration of 'org-code' and 'org-macro' in
order to avoid exaggerations and prevent their compounding effect in
technical documents that include a high concentration of those faces.
They still retain their overall character and continue to look like
variants of 'org-verbatim'.
+ Extended support for Selectrum's new 'selectrum-quick-keys-highlight'
and 'selectrum-quick-keys-match'.
+ Adjusted a few bongo faces for improved consistency and a more
pleasant result overall. Quote from commit 07224cda08:
Refine bongo faces for consistency
The previous design was meant to keep the track fields distinct
from each other. However the use of yellow was not good
aesthetically: it does not fit with the rest of the theme.
Upon further experimentation, I realised that the album field
(yellow) is only present when the artist and title fields are also
available: first is the title, then the artist, and finally the
album. This is true even with 'bongo-join-inserted-tracks' set to
a non-nil value. So changing the face from yellow to a neutral
value is safe.
The other two faces are adapted to look better in the new context.
+ Made more command prompt faces respond to changes in the variable
'modus-themes-prompts'. This concerns faces from the groups cider,
circe, erc, indium, rcirc.
+ Refashioned typescript faces, making them more prominent by default,
while also exposing them to the value of 'modus-themes-syntax'.
+ Revised the style of 'info-colors-ref-item-command'. This makes
commands look the same as functions, which is technically correct. It
also predicates the exact style on the value of the variable
'modus-themes-syntax'.
+ Made all enh-ruby-mode faces adapt to 'modus-themes-syntax'. Same for
julia.
+ Reconfigured all ztree faces for stylistic consistency. The
'ztreep-diff-model-add-face' now responds to the 'deuteranopia' value
that can be passed to 'modus-themes-diffs'.
+ Appended the ':extend t' attribute to 'gnus-summary-cancelled' and
'gnus-summary-selected'. These are only noticeable on Emacs 28
following commit 88409b21c2 in emacs.git.
+ Tweaked all faces of 'highlight-changes-mode' to better deliver on the
intent of that mode.
+ Opted to unconditionally render all 'dired-async' faces in a bold
typographic weight, instead of basing them on a non-nil value for
'modus-themes-bold-constructs'. Also changed 'dired-async-message' to
a blue foreground, which further improves the themes' performance for
red-green colour deficiency.
+ Adjusted the colours of some 'notmuch-crypto-*' faces to better convey
their meaning.
+ Removed remaining conditional logic for underline styles in some
spell- and linter- related faces to ensure that all such cases are
controlled by the variable 'modus-themes-lang-checkers' (building on
work that had been done in the past).
+ Stopped changing 'keycast-key' to match the modeline style, as that
diluted the meaning of the variable 'modus-themes-mode-line'.
+ Tweaked calendar and diary faces for stylistic effect, except for the
'diary' face which has been converted from a green to a blue variant
for the purposes of coping with cases of red-green colour deficiency.
Miscellaneous
-------------
+ Clarified the changes in the backward-incompatible transition from
version 0.13.0 of the themes to >= 1.0.0. Thanks to Damien Cassou for
reporting the absence of easy-to-find information in issue 174:
<https://gitlab.com/protesilaos/modus-themes/-/issues/174>.
+ There were three point releases after 1.2.0 which refined certain
aspects of the themes' packaging so that they could work both as
built-in themes for Emacs as well as in package format via the likes
of GNU ELPA. Those issues were eventually resolved by Basil
L. Contovounesios:
- Issue 162: <https://gitlab.com/protesilaos/modus-themes/-/issues/162>.
- Emacs bug#45068: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45068#218>.
+ Rewrote the 'modus-themes-headings' variable's declaration to improve
its presentation in Custom interfaces. Thanks to Mauro Aranda for
submitting the patch for commit 1c60927ebd.
+ Applied the ':format' keyword to all 'defcustom' forms, based on the
aforementioned patch. This should make all options look better in the
various Custom interfaces. Thanks to Mauro Aranda for the feedback in
issue 163: <https://gitlab.com/protesilaos/modus-themes/-/issues/163>.
+ Refined the colour values 'bg-alt' and 'bg-dim' in 'modus-vivendi' to
improve their instantiation on Textual User Interfaces. In
particular, recalibrated the blue channel of light so that when the
TUI cannot render the colour directly, it defaults to a gray value
instead of a dark blue.
+ Added a "Last-Modified" meta header to modus-themes.el, with gets
updated automatically and uses a timestamp. This helps users who
track the themes' git repo directly. Thanks to Togan Muftuoglu for
the feedback in issue 168:
<https://gitlab.com/protesilaos/modus-themes/-/issues/168>.
+ Expanded the palette of each theme with accent values that are
reserved for use in the tab-bar. Those are used by the newly
supported 'tab-bar-groups' package.
+ Recalibrated a few colour combinations to improve their resulting
legibility. The changes should not be noticeable to the untrained
eye. Interested parties can consult commit 349ea4a943.
+ Tweaked the hueness of the 'yellow-active' colour of 'modus-operandi'.
Thanks once again to everyone involved!
#+end_src
* 1.2.0
:PROPERTIES:
:CUSTOM_ID: h:751083a7-3514-40f5-9928-17a11de5b439
:END:
#+begin_src text
Modus themes version 1.2.0
By Protesilaos Stavrou <info@protesilaos.com> on 2021-03-04
This entry records the changes introduced to the project since the
publication of version 1.1.0 (2021-01-24). There have been close to 100
commits in the meantime.
Every colour-related modification documented 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
combination (the WCAG AAA standard).
As the official manual is referenced several times throughout this log,
make sure to store its URL: <https://protesilaos.com/emacs/modus-themes>. Or
read it from Emacs' Info reader by evaluating this form:
(info "(modus-themes) Top")
If you are coming from older versions, please consult the change log
entry for version 1.0.0 with regard to the breaking changes that were
introduced.
Prior notice: Upgrading the themes in Emacs28 and GNU ELPA
----------------------------------------------------------
Emacs28, the current development target, now includes a 'require-theme'
function. It is a prerequisite to upgrading the Modus themes to their
current version. Prior to the definition of that function, the themes
could not transition from their 0.13.0 version to >=1.0.0. Special
thanks to Basil L. Contovounesios for making it happen, as well Mauro
Aranda and Eli Zaretskii for their feedback and support.
Expect the Modus themes in upstream Emacs to be updated shortly after
the publication of this document.
GNU ELPA currently ships version 0.12.0 of the two standalone packages
'modus-operandi-theme' and 'modus-vivendi-theme'. This will change in
the immediate future, as a new 'modus-themes' package will succeed them.
That new package will be built directly from emacs.git, as it must now
become a ':core' entity instead of being listed as an ':external' one.
Again, expect a patch to be applied to elpa.git shortly after this
document goes live.
Customisation options
---------------------
[ All variables and their values are documented in the themes' manual.
The default value is always nil. ]
+ The new boolean 'modus-themes-subtle-line-numbers' variable will make
the effect of 'display-line-numbers-mode' more subtle when set to a
non-nil value. It removes the underlying background of the unfocused
lines while toning down their foreground.
+ The 'modus-themes-diffs' variable now accepts a 'deuteranopia' value.
This optimises for red-green colour deficiency in all modes that show
diffs (diff-mode, ediff, Magit...). In practice, all instances of
green are replaced with appropriate blue hues. For more on the
matter, read the report which also includes pictures:
<https://protesilaos.com/codelog/2021-02-25-modus-themes-diffs-deuteranopia/>.
+ The 'modus-themes-syntax' variable now reads 'faint-yellow-comments'
as a valid value. This has the same scope as the existing 'faint'
value with the added effect of assigning a yellow tint to comments: it
tones down the saturation of colours that apply to code syntax
(standard font-lock faces and others inheriting from them).
+ The 'modus-themes-links' variable is expanded to accept the new value
of 'neutral-underline-only': it removes the foreground from the link
and draws a neutral gray underline below it.
Refinements to existing packages or face groups
-----------------------------------------------
+ Refashioned all faces that pertain to emails, including Gnus, Mu4e,
Notmuch, and the standard 'message.el' library. This concerns the
colours that apply to the message header keys and their values, as
well as quote levels.
- Introduced more contrasting hues for headings and made more
considerate use of bold typography. The new colour combinations are
better suited for the task of delivering a sense of structure;
structure that is at once effective and subtle.
- Applied less intense colours throughout all quotation levels.
- Revised the sequencing of hues in quotation levels to allow distinct
levels to stand out more without relying on excessive saturation.
- Aligned the styling of Notmuch header dates with their counterparts
in other similar contexts, in pursuit of theme-wide consistency.
+ Rewrote the faces of EBDB to achieve a better sense of structure.
+ Refined the colour combinations of change-log and log-view buffers to
make it easier to discern distinct elements.
+ Tweaked the colours of certain Elfeed constructs to improve the
overall presentation of its search buffers.
+ Changed the colour combinations of 'M-x re-builder' to amplify the
distinction between the matching regexp groups while still reducing
their overall intensity.
+ Reconfigured the 'diff-changed' face to always extend its background
to the edge of the window. Such "changed" lines are visible in
'diff-mode' buffers when the command 'diff-unified->context' is
invoked.
+ Tweaked the colour combinations of ancillary faces in diff buffers
when the variable 'modus-themes-diffs' is set to the value 'fg-only'.
In particular:
- Removed the subtle background from the diff hunk headings and changed
their colour to ensure good visibility---guarantees a sense of
structure.
- Made the context lines inherit the default foreground colour (pure
black/white), so that it contrasts better with red, green, and
yellow text.
- Applied an accented foreground to the diff header. This is to
ensure that it is not mistaken for a diff hunk's context.
All these guarantee that the foreground-only highlights in line-wise
differences draw more attention to themselves.
+ Aligned all the standard hi-* faces with their default aesthetics.
Those are used by commands such as 'highlight-symbol-at-point'.
Thanks to Philip K. for the valuable feedback in issue 157:
<https://gitlab.com/protesilaos/modus-themes/-/issues/157>.
+ Removed obsolete Consult faces and added new ones, so as to remain in
sync with the latest developments in that project. Thanks to Daniel
Mendler (Consult's maintainer) for reporting the inconsistency in
issue 155: <https://gitlab.com/protesilaos/modus-themes/-/issues/155>.
- 'consult-preview-line' now retains fontification on the current
line, instead of applying its own foreground.
- 'consult-narrow-indicator' is refashioned to be colour-coded in a
consistent way with 'consult-async-split', as both denote the
delineation of a given scope.
- 'consult-imenu-prefix' contrasts better with text on its current
line, while it adapts to possible customisations performed on the
Consult front.
+ Expanded the coverage of 'marginalia' faces to two include
'marginalia-char' and 'marginalia-type'. This is done in the interest
of internal consistency between the elements of this set, as their
defaults were also accessible (they inherit from standard faces that
we already support).
+ Opted to render the Notmuch logo in a neutral gray backdrop. This was
deemed necessary as the logo is an immutable image file that consists
of black and white strokes. Black and white are the main background
values of 'modus-vivendi' and 'modus-operandi' respectively, which
could lead to confusion. The neutral gray ensures that the logo is
visible at all times. Thanks to Utkarsh Singh for the feedback in
issue 122: <https://gitlab.com/protesilaos/modus-themes/-/issues/122>.
+ Refined the dedicated colour values used for diff hunk headings, as
seen in diff-mode buffers or Magit. The new colours yield text that
is easier to read by slightly toning down the combined intensity of
background+foreground.
+ Removed the subtle background of 'diff-header' and 'diff-file-header'.
The header's foreground and textual representation suffice to render
it distinct in its context.
+ Tweaked 'org-agenda-structure' and 'org-scheduled' to enhance the
usability of Org Agenda buffers.
- Made 'org-agenda-structure' use the largest possible height that we
expose to users: 'modus-themes-scale-5'.
- Re-calibrated the hueness of 'org-scheduled' and amplified its
saturation, in order to better convey the meaning of a scheduled
task.
Thanks to Morgan Smith for the valuable feedback in issue 153:
<https://gitlab.com/protesilaos/modus-themes/-/issues/153>.
+ Tweaked the faces of the 'bongo' package to enhance the
distinctiveness of the constructs they style.
+ Adjusted the overall aesthetic of calendar faces in the interest of
theme-wide consistency.
+ Aligned the visual metaphors of 'org-code' with those of 'org-macro'
and 'org-verbatim', by ensuring that a subtle background is present
behind the affected text, while the foreground conforms with the norms
of the 'modus-themes-no-mixed-fonts' customisation option.
+ Made quoted text in Info buffers look the same as 'org-verbatim' and
Markdown's inline code.
+ Instructed the faces of 'info-colors' to inherit from appropriate
font-lock faces. This guarantees that everything works as intended
with the various values of 'modus-themes-syntax'.
+ Refined the language tag of Markdown fenced blocks so that it does
attract unwarranted attention while delivering on its intended
purpose.
+ Rendered explicit the slant of ace-window hints, guaranteeing that it
does not inherit from the underlying text. Thanks to Nicolas De
Jaeghere for the patch:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/27>.
[ Some more changes have been discussed, but those require tweaks to
the upstream package. ]
+ Ensured that the 'org-tree-slide-header-overlay-face' never draws an
overline when the variable 'modus-themes-headings' includes a relevant
setting for heading level 1. Such as with the following example (all
customisation options are documented in the themes' manual):
(setq modus-themes-headings
'((1 . section)
...))
+ Extended support for the new 'tab-line-tab-inactive-alternate' face as
that occurs in Emacs28 (current development target). It comes into
effect when the variable 'tab-line-tab-face-functions' includes a
value of 'tab-line-tab-face-inactive-alternating'.
Newly supported packages
------------------------
+ bbdb :: Thanks to Nicolas De Jaeghere in issue 128:
<https://gitlab.com/protesilaos/modus-themes/-/issues/128>.
+ mmm-mode :: Thanks to Davor Rotim for the feedback in issue 161:
<https://gitlab.com/protesilaos/modus-themes/-/issues/161>.
+ quick-peek :: Thanks to Burgess Chang for the feedback in issue 151:
<https://gitlab.com/protesilaos/modus-themes/-/issues/151>
+ selectrum-prescient :: This new package was brought to my attention by
Manuel Uberti. The intent is to phase out the faces in Selectrum,
namely 'selectrum-primary-highlight', 'selectrum-secondary-highlight',
though those will still be supported by the Modus themes for the
foreseeable future.
+ shortdoc
+ spray
+ terraform-mode :: Thanks to Kevin Fleming for the feedback in issue
159: <https://gitlab.com/protesilaos/modus-themes/-/issues/159>.
+ vc-dir (Emacs28)
Theme-related contributions to the wider community
--------------------------------------------------
+ Contributed the faces for 'vc-dir' in Emacs28 and applied them to all
VC backends: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46358> and
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46745>.
+ Contributed a new face and some related tweaks to Emacs'
'shortdoc.el': <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=46748>.
+ Added faces to the 'tab-bar-echo-area.el' package:
<https://github.com/fritzgrabo/tab-bar-echo-area/pull/2>.
+ Reported issue that led to the review of the header face in
'org-tree-slide': <https://github.com/takaxp/org-tree-slide/issues/38>.
+ Helped refine the faces of the 'rlist.el' package:
<https://gitlab.com/mmemmew/rlist/-/commit/386f506d0110bebedd3a48ff972adba96e2232eb>.
Documentation updates
---------------------
+ Wrote about the indirect support for the 'goggles' package. I had
helped write its faces, as was documented in the changelog for version
1.1.0 of the themes. Thanks to Manuel Uberti for bringing this to my
attention in issue 158:
<https://gitlab.com/protesilaos/modus-themes/-/issues/158>.
+ Explained that any changes to 'custom-theme-load-path' and/or
'custom-theme-directory' should be performed before the themes are
loaded. Thanks to Adrian Manea for the feedback in issue 156:
<https://gitlab.com/protesilaos/modus-themes/-/issues/156>.
+ Included the symbol 'bg-only' in the 'modus-themes-diffs' section of
the manual. Thanks to user "iSeeU" for reporting the omission:
<https://gitlab.com/protesilaos/modus-themes/-/issues/154>.
+ Expanded the manual's entry on the semantics of the optional heading
scale used by the themes (the variables 'modus-themes-scale-[1-5]').
The values 1-4 apply to regular headings, with 4 being the largest on
the scale. While 'modus-themes-scale-5' is reserved for special
headers, such as Org '#+title:' or the Org Agenda's structure. Recall
that those variables only come into effect if the boolean variable
'modus-themes-scale-headings' is set to a non-nil value (it is nil by
default).
+ Made several changes to the 'modus-themes.org' file in an effort to
improve the accuracy of the generated Texinfo markup. Thanks to Glenn
Morris and Richard Stallman for their valuable feedback in
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45143>.
+ Recorded a note in the manual on the intended colouration of
backgrounds applied by 'mmm-mode'. It explains what the constraints
are from an accessibility standpoint and how users can configure
things locally for more colourful, yet inaccessible, backgrounds.
Thanks to Davor Rotim for the valuable feedback in issue 161:
<https://gitlab.com/protesilaos/modus-themes/-/issues/161>.
+ Refined the manual's note on prism.el, simplifying the code samples
and clarifying the commentary.
+ Wrote indices for concepts, variables, functions, which are rendered
in the Info manual.
+ Elaborated on the possibility---and relative merits---of implementing
a theme-agnostic hook for advanced face configurations, as opposed to
relying on 'modus-themes-after-load-theme-hook'. Thanks to Daniel
Mendler for the valuable feedback in issue 131:
<https://gitlab.com/protesilaos/modus-themes/-/issues/131>.
Miscellaneous
-------------
+ Rewrote the documentation string of the 'deftheme' declaration of
'modus-operandi' and 'modus-vivendi'.
+ Provided links to the Info nodes that discuss each of the 'defcustom'
declarations.
+ Wrote doc strings for every custom face that the themes define.
#+end_src
* 1.1.0
:PROPERTIES:
:CUSTOM_ID: h:bb0e16a9-8a8b-4b1b-9d62-b1715295247b
:END:
#+begin_src text
Modus themes version 1.1.0
By Protesilaos Stavrou <info@protesilaos.com> on 2021-01-24
This entry records the changes introduced to the project since the
publication of version 1.0.0 (2020-12-05). There have been around 150
commits in the meantime, qualifying this as one of the largest releases
to date.
As always, every colour-related modification documented 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 combination (conformance with the WCAG AAA standard).
As the official manual is referenced several times, make sure to store
its URL: <https://protesilaos.com/emacs/modus-themes>.
If you are coming from older versions, please consult the change log
entry for version 1.0.0.
Overview
--------
+ We have brought back the options that were present in version 0.13.0
or earlier which allowed users to override colors for either---or
both---of Modus Operandi and Modus Vivendi. Compared to the old
mechanism, the new one is more robust and should work regardless of
whether users run byte compiled code or not. This is considered and
advanced, "do-it-yourself" pathway to theme customisation. It is
discussed at length in the manual.
+ The new 'modus-themes-with-colors' macro makes it possible to read
palette variables from the active theme and, thus, pass them to
arbitrary functions or variables. Again, this is part of the advanced
customisations that are covered in the manual.
+ Several of the existing customisation options provide new stylistic
variants, further expanding their utility. While there are some new
customisations altogether. Combined with the above, we provide the
infrastructure that allows the themes to adapt gracefully to a variety
of circumstances and cover a broad range of demands.
+ More packages are added to the already comprehensive list of supported
face groups.
+ Some of the supported faces have benefited from further, albeit
subtle, refinements, demonstrating our commitment to consistency as
well as our attention to detail.
+ Two reports on such "further refinements" were published on the code
log section of protesilaos.com: <https://protesilaos.com/codelog>.
+ We have more people contributing to the project (and assigning
copyright to the FSF---as the themes are part of Emacs) and newer
users reporting issues. Also, there is anecdotal evidence from
several sources on an increased interest to make new or existing faces
accessible by default (such as by copying colour combinations from the
themes).
New customisation options
-------------------------
+ The existing 'modus-themes-mode-line' variable now supports three new
borderless styles: 'borderless', 'borderless-3d', 'borderless-moody'.
- The 'borderless' value uses the same colors as the default (nil
value), but removes the border effect. This is done by making the
box property use the same color as the background, effectively
blending the two and creating some padding.
- The 'borderless-3d' and 'borderless-moody' approximate the '3d' and
'moody' options respectively, while removing the borders. However,
to ensure that the inactive modelines remain visible, they apply a
slightly more prominent background to them than what their
counterparts do (same inactive background as with the default).
The complete list of options:
1. nil (default)
2. 3d
3. moody
4. borderless
5. borderless-3d
6. borderless-moody
+ 'modus-themes-lang-checkers' provides several styles for spell
checkers and code linters with regard to how they underline text. The
default (nil) is to use a colour-coded wavy underline, without
changing the foreground of the affected text. Other options include
the ability to set a straight underline and to control the saturation
of the foreground, while one also provides for a change in the
background of the text in question. The valid symbols are as follows
(read the manual for more on the matter):
1. nil (default)
2. straight-underline
3. subtle-foreground
4. subtle-foreground-straight-underline
5. intense-foreground
6. intense-foreground-straight-underline
7. colored-background
+ The 'modus-themes-org-habit' lets users pick between three styles for
the 'org-habit' table: (1) nil (the default), which uses a total of
eight colours, (2) 'simplified' which reduces the effective colours to
four, while applying less saturated hues, and (3) 'traffic-light'
which bring the colour count to three, thus blending the "clear" and
"ready" states for workflows where the distinction between is not
useful.
Please read the manual for a more detailed description of those
variants.
Thanks to Gustavo Barros for suggesting the idea, providing user
feedback on stylistic choices, as well as sharing insights on the
workflow that made the 'traffic-light' style possible:
<https://gitlab.com/protesilaos/modus-themes/-/issues/135>.
+ 'modus-themes-variable-pitch-ui' when set to a non-nil value applies a
proportionately spaced typeface (controlled by the 'variable-pitch'
face) to the User Interface, specifically the mode line, header line,
and tab-{bar,line}.
+ The existing 'modus-themes-links' variable now has a colourless
stylistic alternative: 'underline-only'. The available styles:
1. nil (default)
2. faint
3. neutral-underline
4. faint-neutral-underline
5. no-underline
6. underline-only
+ The existing 'modus-themes-prompts' variable has two new grayscale
styles: 'subtle-gray', 'intense-gray'. Furthermore, their old
'subtle' and 'intense' values have more informative aliases in the
form of 'subtle-accented' and 'intense-accented'. All available
values:
1. nil (default)
2. subtle-accented ('subtle' remains for backward-compatibility)
3. intense-accented ('intense' remains for backward-compatibility)
4. subtle-gray
5. intense-gray
+ The existing 'modus-themes-headings' variable now accepts two new
styles: 'no-color', 'no-color-no-bold'. All stylistic variants:
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
17. no-color
18. no-color-no-bold
Please read the manual for instructions on how to apply those
universally or on a per-level basis.
Added support for packages
--------------------------
+ cfrs (used by treemacs)
+ cperl-mode
+ diredc
+ display-fill-column-indicator-mode. Thanks to Gustavo Barros for the
feedback: <https://gitlab.com/protesilaos/modus-themes/-/issues/148>.
+ evil-snipe. Thanks to Peter Wu for the feedback:
<https://gitlab.com/protesilaos/modus-themes/-/issues/139>.
+ isl (isearch-light). Thanks to Manuel Uberti for the feedback:
<https://gitlab.com/protesilaos/modus-themes/-/issues/144>.
+ marginalia
+ org-tree-slide
+ recursion-indicator
+ solaire. Thanks to CsBigDataHub1 for the feedback:
<https://gitlab.com/protesilaos/modus-themes/-/issues/137>.
Refinements to already supported faces
--------------------------------------
+ Reviewed the 'rainbow-delimiters' faces. Everything is documented in
a separate report (with screenshots). The short version is that we
pay close attention to detail and are willing to go to great lengths
in pursuit of improving the overall user experience:
<https://protesilaos.com/codelog/2020-12-27-modus-themes-review-rainbow-delimiters/>.
+ Updated the dedicated colours for 'whitespace-mode'. The background
should now be easier to discern. Also removed any remaining
inconsistencies. Thanks to Toon Claes for the feedback:
<https://gitlab.com/protesilaos/modus-themes/-/issues/149>.
+ Refined the faces of regexp constructs for strings affected by certain
values passed to the 'modus-themes-syntax' option. This is done to
disambiguate the backslashes and grouping delimiters from the rest of
the string. The relevant values for 'modus-themes-syntax' are:
- green-strings
- yellow-comments-green-strings
- alt-syntax
- alt-syntax-yellow-comments
The default colour for strings is blue, while regexp faces are yellow
and red, whereas in those variants the strings become green, hence the
need to make regexp faces more distinct (blue and magenta contrast
better with green and also between themselves, thus matching the
alternative aesthetics).
+ Reviewed dictionary.el faces (which ships with Emacs 28):
- Made 'dictionary-reference-face' look like all other links.
- Removed all properties from 'dictionary-word-definition-face':
the default sets a font family, which can create inconsistencies.
- Converted 'dictionary-word-entry-face' into comment-like text.
+ Refined and expanded the faces of Consult.
- Made its grep commands look the same as those of all other grep
tools.
- Ensured that line number previews, such as for the 'consult-line'
command use their own style of a subtle foreground instead of
inheriting from the 'line-number' face. This is to avoid cases
where previewed numbers and actual line numbers could be conflated
for one another.
- Removed the foreground pertinent to 'consult-imenu-prefix', as its
bold weight combined with the structure of Imenu indices was deemed
sufficient to differentiate it from actual 'consult-imenu' targets.
+ Eliminated exaggerations in the use of colour for various 'which-key'
faces.
+ Removed the needless background from the 'log-view-commit-body' face.
This is a new face that ships with Emacs 28 (its inclusion upstream
was documented in the last changelog entry).
+ Applied a subtle background to the 'log-view-message' face, in the
interest of improving the usability of its interface, in particular,
to contribute to heightened situational awareness while invoking
'log-view-toggle-entry-display' in buffers such as those produced by
'vc-print-root-log'.
+ Introduced a neutral background for all 'outline-minor-faces' instead
of merely mirroring the style of 'outline-mode' headings. This is
because it can sometimes be hard to tell whether 'outline-minor-mode'
is active, provided certain fairly common configurations in the
'modus-themes-headings' user option (refer to the manual for all
customisation options).
+ Tweaked 'diff-mode' headings.
- Adjusted the values of the dedicated colours for diff headings in
order to amplify their relative contrast.
- Assigned a bold typographic weight to the 'diff-hunk-header' face so
as to enforce a greater sense of structure.
- Instructed 'diff-function' to inherit 'modus-theme-diff-heading' in
order to eliminate exaggerations in colouration.
+ Removed unnecessary underline from 'selectrum-current-candidate'.
Thanks to Daniel Mendler for the feedback:
<https://gitlab.com/protesilaos/modus-themes/-/issues/132>.
+ Made 'counsel-outline' inherit from the underlying Org faces. Also
corrected the style of 'counsel-outline-default' to use the main
foreground colour. Thanks to Gustavo Barros for the feedback:
<https://gitlab.com/protesilaos/modus-themes/-/issues/134>.
+ Prevented headings, ultimately governed by the 'modus-themes-headings'
user option, from inheriting the 'default' face as that could lead to
unintended consequences, such as by retaining a background colour when
none was expected.
+ Refashioned all faces that specified a foreground value of 'fg-alt' to
inherit the 'shadow' face instead ('fg-alt' is the colour that is
used, for example, in code comments by default). This makes it
possible for users to enact change across the theme just by tweaking
'shadow'.
+ Fixed 'ruler-mode' text scaling adjustment, to make it cope well with
'text-scale-adjust' and relevant commands. Also introduced minor
stylistic changes to the remainder of the 'ruler-mode' faces.
+ Eliminated the potentially problematic form of ':foreground nil' from
the 'org-ellipsis' face. In such cases it is always better to either
specify no foreground whatsoever, or declare an unspecified value.
Patches from the community
--------------------------
Remember that the themes are part of Emacs and, thus, contributions that
exceed a cumulative total of ~15 lines require the assignment of
copyright to the Free Software Foundation. Please consult the themes'
manual on the matter.
+ Nicolas De Jaeghere added support for 'exwm-floating-border-color':
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/15>.
+ Anders Johansson added support for 'helm-fd-finish':
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/16>.
+ Carlo Zancanaro fixed misquoting of 'tuareg-font-lock-multistage-face':
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/17>.
+ Xinglu Chen expanded Notmuch support to all its remaining faces:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/18>.
+ Kostadin Ninev added support for Dired+:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/19>.
+ Nicolas De Jaeghere expanded the supported items of 'pdf-faces'. Also
added an entry to the manual pertaining to link hints and the
requisite setup:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/20>.
+ Nicolas De Jaeghere wrote the new 'modus-themes-with-colors' macro,
which is documented at length in the manual:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/21>.
+ Nicolas De Jaeghere set up the infrastructure that grants users the
ability to override palette colors; an option that was removed in the
transition from version 0.13.0 to 1.0.0. The relevant variables are
'modus-themes-colors-operandi', 'modus-themes-colors-vivendi' (again,
consult the manual):
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/23>.
+ Nicolas De Jaeghere deleted the 'modus-themes-core.el' file and merged
its contents into the main 'modus-themes.el' library:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/24> and
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/25>.
+ Nicolas De Jaeghere made the 'compilation-info' face consistent with
other compilation faces in terms of their optional bold weight:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/26>.
Any remaining faults that may exist, despite our best intentions to
remove them, are those of the maintainer and will be addressed as soon
as they are identified.
FSF copyright status:
| Full name | Copyright |
|---------------------+--------------|
| Anders Johansson | covered |
| Carlo Zancanaro | not required |
| Kostadin Ninev | covered |
| Nicolas De Jaeghere | covered |
| Xinglu Chen | not required |
Theme-related contributions to the wider community
--------------------------------------------------
+ Helped address an incomplete colour value in 'org-transclusion-block':
<https://github.com/nobiot/org-transclusion/issues/41>.
+ Contributed to the formation of the zebra striping of 'embark':
<https://github.com/oantolin/embark/commit/bb4ae2a666ab1f4a307edd71f77bcbb90fb25cef>.
+ Reviewed the faces of 'goggles':
<https://github.com/minad/goggles/commit/d6e584a2c9487d3df4aee818c43485e437cb87ef>.
+ Helped raise awareness about refactoring 'org-tree-slide-header-overlay-face':
<https://github.com/takaxp/org-tree-slide/issues/38>.
+ Reported an issue for Moody that would affect the subset of Emacs 28
users who enable the new 'mode-line-compact' option:
<https://github.com/tarsius/moody/issues/28>.
+ Did the same for Keycast: <https://github.com/tarsius/keycast/issues/13>.
+ Defined the new 'perl-non-scalar-variable' in upstream Emacs:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45840>.
Miscellaneous
-------------
+ Created a new palette subset for "graph" colours, as none of the
existing paradigms would suffice for cases where faithfulness to
colour huenesss is important. Those are currently used by
'modus-themes-org-habit'.
+ Ensured that theme functions which need to produce an error message do
so by calling 'error' instead of 'user-error'.
+ Added a 'modus-themes-load-themes' function that users can add to
their init files.
+ Expanded the project's git repo README file with a sample
'use-package' configuration.
+ The previous two points followed from an inquiry into the subtleties
between 'enable-theme' and 'load-theme'. Those are now documented at
length in the manual.
+ Added screenshots to the web page that holds the official manual.
Thanks to Damien Cassou for the feedback:
<https://gitlab.com/protesilaos/modus-themes/-/issues/147>.
+ Swapped the values of 'cyan-faint' and 'cyan-alt-faint' for Modus
Vivendi.
+ Tweaked 'font-lock-doc-face' and 'font-lock-type-face' variations when
"faint syntax" is in effect: (setq modus-themes-syntax 'faint).
+ Refined 'font-lock-doc-face' for when modus-themes-syntax is given a
value of either 'yellow-comments-green-strings' or 'green-strings'.
The changes are minor when treated in isolation, though they have
helped improve the overall consistency of the end result: the gestalt.
+ Reviewed select "faint" colours for both Modus Operandi and Modus
Vivendi. The technicalities are discussed in a complete report:
<https://protesilaos.com/codelog/2021-01-11-modus-themes-review-select-faint-colours/>.
+ Ensured that (setq modus-themes-syntax 'alt-syntax) and its "yellow
comments" variant are more truthful to their intended style, by
eliminating any exaggerations in the use of colour.
+ Adjusted the saturation of the green-alt value of Modus Vivendi.
+ Updated the manual to reflect all of the aforementioned.
Thanks once again to everyone who contributed patches or reported an
issue. This has been yet another period of intense work; work which
helps solidify the Modus themes as (i) uncompromisingly accessible in
accordance with the highest legibility standard, (ii) highly
customisable in true Emacs fashion, (iii) thoroughly comprehensive in
terms of face coverage, and (iv) meticulously designed throughout.
#+end_src
* 1.0.0
:PROPERTIES:
:CUSTOM_ID: h:94b5915e-1085-4859-ac9f-daf91e007741
:END:
#+begin_src text
Modus themes version 1.0.0
By Protesilaos Stavrou <info@protesilaos.com> on 2020-12-05
This entry documents the changes since version 0.13.0 (2020-10-08).
They constitute a major release with backward-incompatible additions
which are described below.
As always, every colour-related modification documented 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 combination (conformance with the WCAG AAA standard).
Expect to find examples of basic and advanced customisations in the
comprehensive Info manual bundled with the themes, which is also
available at: <https://protesilaos.com/emacs/modus-themes>.
Overview of major changes
=========================
0. The option that was present in earlier releases to override the
colour palette has been removed. It cannot work with byte
compilation. We must not compromise on performance, especially in
light of the fairly high line count of the themes (broad face
coverage combined with a multitude of customisation options).
1. The code base has been refactored. The two themes, Modus Operandi
(light) and Modus Vivendi (dark), derive from the same source.
2. The refactoring makes it possible to distribute the two themes as
part of a single package. You can find 'modus-themes' on MELPA, with
other archives and core Emacs following suit soon thereafter (the
Modus themes are built into Emacs since their version 0.12.0).
3. The 'modus-operandi-theme' and 'modus-vivendi-theme' packages in
MELPA and GNU ELPA are obsolete. MELPA has already deleted them and
now only provides 'modus-themes', while GNU ELPA shall do so soon
enough.
+ Package providers of GNU/Linux distros, or other archives, are
encouraged to update their sources so that they only deliver a
single package that covers both themes.
4. To avoid surprises, the refactored code is in the 'main' branch which
becomes the default henceforth. The 'master' branch, from where all
prior releases were built, is thus deprecated. Existing installs of
'modus-operandi-theme' and/or 'modus-vivendi-theme' must manually
switch to the new package sources, which offer a certain guarantee
that they are informed of the breaking changes documented herein.
+ Users of 'straight.el' must make sure that they pull from the
'main' branch. This may also be the case for other such tools,
though I have not had the time to test them all.
5. The refactoring introduces a unified customisation framework. Now
all user-facing variables are named 'modus-themes-*' instead of
'modus-operandi-*' and 'modus-vivendi-*'. Users of both items can
thus cut down on duplicate code or inelegant workarounds on their
end. Example:
modus-operandi-bold-constructs
| | | | | | | ====> modus-themes-bold-constructs
modus-vivendi-bold-constructs
6. The themes now provide common user-facing functions.
+ 'modus-themes-load-operandi' and 'modus-themes-load-vivendi' can be
used in Lisp to load the theme they name, while disabling their
counterpart and running 'modus-themes-after-load-theme-hook'. The
hook can be used to override or further customise faces (examples
are furnished in the manual).
+ 'modus-themes-toggle' interactively switches between Modus Operandi
and Modus Vivendi or opens a minibuffer prompt to select between
the two if none of them is active. It ultimately calls the
aforementioned functions to load the themes, so it also triggers
the hook. Bind this command to a key of your convenience (the
author uses F5).
+ 'modus-themes-color' returns the colour value of a symbol in the
alists that hold the themes' palettes. The alists are
'modus-themes-colors-operandi' and 'modus-themes-colors-vivendi'.
'modus-themes-color' always operates on the active theme, making it
suitable for post-theme-load customisations (via the hook we
covered earlier). Its usage is documented in the manual and is
meant to be employed by those who are prepared to assume
responsibility for face-related changes they introduce on their
setup.
+ 'modus-themes-color-alts' occupies the same niche as the one right
above, with the exception that it takes two arguments. The first
is the alist key to be used by 'modus-operandi' and the second is
for 'modus-vivendi'.
+ 'modus-themes-wcag-formula' implements the WCAG formula to measure
a colour value's relative luminance. While 'modus-themes-contrast'
applies the formula to derive the contrast ratio between two colour
values in hexadecimal RGB notation. This can be used to verify the
accessibility of colour combinations provided by the themes or new
ones defined at the user level (the Modus themes conform with the
WCAG AAA standard which means that this kind of contrast is 7:1 or
higher for all applicable background+foreground combinations).
Customisation options
=====================
This is the complete list with all the customisation options:
modus-themes-slanted-constructs (boolean)
modus-themes-bold-constructs (boolean)
modus-themes-variable-pitch-headings (boolean)
modus-themes-no-mixed-fonts (boolean)
modus-themes-headings (alist)
modus-themes-scale-headings (boolean)
modus-themes-fringes (choice)
modus-themes-org-blocks (choice)
modus-themes-prompts (choice)
modus-themes-mode-line (choice)
modus-themes-diffs (choice)
modus-themes-syntax (choice)
modus-themes-intense-hl-line (boolean)
modus-themes-paren-match (choice)
modus-themes-region (choice)
modus-themes-links (choice)
modus-themes-completions (choice)
Plus those which are contingent on 'modus-themes-scale-headings':
modus-themes-scale-1
modus-themes-scale-2
modus-themes-scale-3
modus-themes-scale-4
modus-themes-scale-5
Consult the manual for each of them and please verify that none of the
older options remains in your init file.
Customisation options that did not exist in earlier versions
------------------------------------------------------------
New entries and their possible values:
1. modus-themes-syntax
,* nil (default)
,* faint
,* yellow-comments
,* green-strings
,* yellow-comments-green-strings
,* alt-syntax
,* alt-syntax-yellow-comments
(supersedes options for "faint syntax" and "comments")
2. modus-themes-links
,* nil (default)
,* faint
,* neutral-underline
,* faint-neutral-underline
,* no-underline
(supersedes options for "no underlines")
3. modus-themes-paren-match
,* nil (default)
,* intense
,* subtle-bold
,* intense-bold
(supersedes options for "intense paren match")
4. modus-themes-region
,* nil (default)
,* no-extend
,* bg-only
,* bg-only-no-extend
Furthermore, the 'modus-themes-diff' has a new option to choose from:
the symbol 'bg-only'. It applies colour-coded backgrounds but does not
override any syntax highlighting that may be present. This makes it
suitable for use with a non-nil value for diff-font-lock-syntax (which
is the default for diff-mode buffers in Emacs 27 or higher).
Support for new faces or face groups
====================================
+ consult
+ macrostep
+ make-mode
+ pdf-tools
+ popup
+ shr
+ sieve-mode
(remember that the list of supported packages is already comprehensive)
Thanks to:
+ Adam Spiers for bringing 'macrostep' to my attention.
+ Madhavan Krishnan for submitting the code for pdf-tools:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/14>.
+ Manuel Uberti for reporting the issue with popup.el:
<https://gitlab.com/protesilaos/modus-themes/-/issues/107>.
+ Again thanks to Manuel for consult:
<https://gitlab.com/protesilaos/modus-themes/-/issues/123>. And to
Daniel Mendler, its developer, for communicating with us on the status
of the project.
+ Togan Muftuoglu for reporting the issue with sieve-mode:
<https://gitlab.com/protesilaos/modus-themes/-/issues/121>.
Refinements to existing faces
=============================
+ The diary and holiday marks in 'M-x calendar' are displayed using a
slightly tinted background in order to improve their contrast.
Holidays are also rendered in a bold font. Thanks to Nicolas De
Jaeghere for reporting the issue and following it up with valuable
feedback: <https://gitlab.com/protesilaos/modus-themes/-/issues/127>.
+ Code blocks in 'markdown-mode' now have a subtle background that
extends to the edge of the window. Thanks to Roman Rudakov for the
suggestion and Hörmetjan Yiltiz for further testing:
<https://gitlab.com/protesilaos/modus-themes/-/issues/115>.
+ Inline code in 'markdown-mode' has a subtle background that covers the
length of the construct. Refer to issue #115 as above.
+ Ivy's main pattern-matching faces are slightly adjusted to work more
effectively when users opt for "modus-themes-completions 'moderate" or
"modus-themes-completions 'opinionated".
+ Swiper's 'swiper-isearch' command defaults to a more colourful
presentation that clearly disambiguates matching pattern groups
between themselves as well as their own active and inactive states.
Thanks to John Haman for reporting the problem:
<https://gitlab.com/protesilaos/modus-themes/-/issues/125>.
+ Swiper's remaining faces are tweaked to better convey the intent of
this tool.
+ The border of 'ivy-posframe' is more noticeable. Thanks to Pete
Kazmier: <https://gitlab.com/protesilaos/modus-themes/-/issues/126>.
+ The 'fringe' face no longer returns a nil background, which allows
'dap-ui-controls-mode' to display things properly. Thanks to Simon
Pugnet: <https://gitlab.com/protesilaos/modus-themes/-/issues/106>.
+ Tags and priority cookies in Org mode no longer have a box property.
This is because of changes in upstream Org that we helped solve and
that are covered in the previous CHANGELOG entry (in short: Org
heading constructs inherit the underlying heading's properties that
are not part of their own specs, while they retain those that are
explicitly defined for them---adaptive headings). Properly solves the
following issues:
,* <https://gitlab.com/protesilaos/modus-themes/-/issues/104>. Thanks
to user "bepolymathe".
,* <https://gitlab.com/protesilaos/modus-themes/-/issues/95>. Thanks
to Roman Rudakov.
+ The faces of 'M-x re-builder' are less intrusive.
+ All the following now inherit from basic font-lock faces and thus
benefit from options such as 'modus-themes-syntax':
,* geiser
,* nxml-mode
,* tuareg
,* web-mode
,* xah-elisp-mode
+ Diff headers have a subtle grey background that extends to the edge of
the window.
+ The faces of log-view and change-log use colour combinations that
better differentiate the various objects on display.
+ 'font-lock-type-face' uses a cyan hue instead of magenta.
+ 'magit-header-line-key' uses a blue foreground colour instead of red.
+ Doc strings in code syntax are rendered in a new dedicated colour.
The change is fairly subtle and should practically go unnoticed.
+ 'org-date' now respects the 'modus-themes-no-mixed-fonts' option.
Thanks to user "fleimgruber" for reporting the issue:
<https://gitlab.com/protesilaos/modus-themes/-/issues/124>.
+ 'org-property-value' uses a slightly different shade of cyan.
+ 'dim-autoload' will always look like a regular comment.
+ The 'italic' face is inhereted by all relevant faces instead of
hard-wiring a slant property. This offers the potential advantage of
specifying a distinct family (or other properties) for constructs that
are meant to be rendered in italics (the manual has an example in its
DIY sections for this scenario though it uses the 'bold' face---just
apply the same idea to the 'italic' face).
+ 'dictionary-reference-face' inherits from 'button' (as with all
links).
+ Several comment-related faces beyond the basic ones work with
'modus-themes-syntax' when that has an effect on the colour of
comments. The faces are:
,* git-commit-comment-file
,* git-commit-comment-heading
,* git-rebase-comment-hash
,* git-rebase-comment-heading
+ 'transient-value' is more noticeable and fits better in its context.
+ All remaining Org metadata-related faces are refined for consistency
between them in an attempt to make them unobtrusive. More subtle
colouration is applied. Affected faces:
,* org-drawer
,* org-property-value
,* org-special-keyword
Theme-related contributions to the wider community
==================================================
+ Defined the 'log-view-commit-body' for Emacs 28.1:
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-11/msg00303.html>
and
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-11/msg02196.html>.
+ Specified the version of the 'diff-error' face for Emacs 28.1:
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-11/msg01328.html>.
+ Added the 'org-dispatcher-highlight' face to upstream Org:
<https://lists.gnu.org/archive/html/emacs-orgmode/2020-10/msg00158.html>.
,* Report with screenshots:
<https://protesilaos.com/codelog/2020-10-24-org-export-dispatcher-face/>.
+ Helped fix face of Flymake's unknown backend in inactive modelines:
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-11/msg01119.html>.
+ Solved bug#44198 about a user not knowning the themes are in Emacs:
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-10/msg02001.html>.
Miscellaneous
=============
+ The new default 'main' branch of the Modus themes' git repo is an idea
that was presented by user "Emacs Contrib" in issue 112:
<https://gitlab.com/protesilaos/modus-themes/-/issues/112>. Raising
awareness about the negative impact of potentially, tacitly, or
explicitly offensive language is a goal worth pursuing. Plus "main"
is a more appropriate name for the primary branch of a project and we
do not lose anything by introducing this change as part of version
1.0.0, which anyhow requires manual interventions in user
configurations.
+ Thanks to Manuel Uberti, Jeremy Friesen, and Gitlab user "Eugene" for
their feedback during the process that eventually led to the
development of the 'modus-themes-syntax' customisation option:
<https://gitlab.com/protesilaos/modus-themes/-/issues/105>.
+ Thanks to André Alexandre Gomes for the feedback in issue 111, which
led to the simplification of the manual's references to Guix:
<https://gitlab.com/protesilaos/modus-themes/-/issues/111>.
+ Thanks to Nicolas De Jaeghere for noting that BBDB is indirectly
supported: <https://gitlab.com/protesilaos/modus-themes/-/issues/128>.
Between the refactoring of the code base and all other changes, this has
been yet another period of hard work to deliver on the promise of themes
that are (i) highly accessible and (ii) comprehensive in both their face
coverage and customisation options, while always conforming with the
highest accessibility standard for legible text.
Special thanks to the MELPA maintainers for all their contributions.
MELPA is an integral part of the wider Emacs community. Thanks, in
particular, to Chris Rayner who has reviewed all my pull requests
hitherto, and to Jonas Bernoulli for checking the latest one (and its
concomitant issue) that introduced the new 'modus-themes' package.
Thank you, the reader, for your attention and for understanding the
longer term benefits of the refactoring, despite the short term friction
it may have introduced.
#+end_src
* 0.13.0
:PROPERTIES:
:CUSTOM_ID: h:b529ec46-2a9f-4844-9760-4708d2ca575b
:END:
#+begin_src text
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):
+ modus-operandi-theme-diffs
+ modus-vivendi-theme-diffs
Possible values:
1. nil (default)
2. desaturated
2. fg-only
DEPRECATED ("boolean" type):
+ modus-operandi-theme-subtle-diffs
+ modus-vivendi-theme-subtle-diffs
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):
+ modus-operandi-theme-mode-line
+ modus-vivendi-theme-mode-line
Possible values:
1. nil (default)
2. 3d
3. moody
DEPRECATED ("boolean" type):
+ modus-operandi-theme-3d-modeline
+ modus-vivendi-theme-3d-modeline
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):
+ modus-operandi-theme-headings
+ modus-vivendi-theme-headings
DEPRECATED ("boolean" type):
+ modus-operandi-theme-rainbow-headings
+ modus-operandi-theme-section-headings
+ modus-vivendi-theme-rainbow-headings
+ modus-vivendi-theme-section-headings
Possible values, which can be specified for each heading level (examples
further below):
0. nil (default fallback option---covers all heading levels)
1. t (default style for a single heading, when the fallback differs)
2. no-bold
3. line
4. line-no-bold
5. rainbow
6. rainbow-line
7. rainbow-line-no-bold
8. highlight
9. highlight-no-bold
10. rainbow-highlight
11. rainbow-highlight-no-bold
12. section
13. section-no-bold
14. rainbow-section
15. 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):
+ modus-operandi-theme-no-link-underline
+ modus-vivendi-theme-no-link-underline
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):
+ modus-operandi-theme-no-mixed-fonts
+ modus-vivendi-theme-no-mixed-fonts
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
====================================
+ awesome-tray
+ binder
+ cperl-mode
+ eldoc-highlight-function-argument
+ erc escaped colour sequences
+ eshell-syntax-highlighting
+ flycheck-color-mode-line
+ isearch regexp groups (Emacs version >= 28)
+ mpdel
+ objed
+ org 9.4 new faces: 'org-headline-todo' and 'org-table-header'
+ racket-mode
+ typescript-mode
Thanks to:
+ Damien Cassou for reporting the issue with mpdel:
<https://gitlab.com/protesilaos/modus-themes/-/issues/99>
+ Dario Gjorgjevski for reporting the issue with erc:
<https://gitlab.com/protesilaos/modus-themes/-/issues/92>
+ Markus Beppler for contributing the patch for cperl-mode:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/11>
+ User "Moesasji" for reporting the issue with objed:
<https://gitlab.com/protesilaos/modus-themes/-/issues/79>
Refinements to existing faces
=============================
+ calfw applies colours and styles in a way that makes it consistent
with the rest of the themes' metaphors.
+ diredfl makes more considerate use of colour. We still apply colour
everywhere (the whole point of this package) but make sure to avoid
exaggerations.
+ doom-modeline-battery-error face fits better with the rest of the
design.
+ elfeed search buffers use less intense colours, while still keeping
all elements fairly distinct. The intent is to avoid a "rainbow
effect" in such a dense interface.
+ elfeed read and unread items are more distinct.
+ git commit and vc log edit messages benefit from refined colour
combinations for their various constructs. The commit's summary is
now rendered in a bold weight, to better convey the idea that this is
a quasi heading element.
+ gnus heading colours are more consistent. All information remains
clearly distinct, but we now avoid using colours that are on opposite
sides of the colour spectrum. Basically to keep things distinct
without going over the top.
+ gnus read and unread items are easier to tell apart. Thanks to user
"Nick" for reporting the issue:
<https://gitlab.com/protesilaos/modus-themes/-/issues/97>.
+ help-argument-name has a distinct foreground colour, so that it is
easier to spot it in "*Help*" buffers. Its slant is also controlled
by the active theme's customisation option for slanted constructs (nil
by default---check the manual).
+ helpful-heading now is consistent with other heading styles. Thanks
to Nicolas De Jaeghere for reporting the issue:
<https://gitlab.com/protesilaos/modus-themes/-/issues/90>.
+ icomplete, ido, orderless are all tweaked to work better under various
circumstances.
+ info-menu-star uses a red colour to make it easier to select a menu
entry by estimating its number. This face applies to every third
element and is a nice little extra to have.
+ info quoted strings are configured to always render in 'fixed-pitch',
in line with the themes' design for mixed fonts (remember to check the
relevant customisation option).
+ line numbers work properly with 'text-scale-adjust'. Thanks to user
"jixiuf" for reporting the issue:
<https://gitlab.com/protesilaos/modus-themes/-/issues/98>.
+ line-number-current-line no longer applies a bold weight to its text.
This is to avoid a certain "jump effect" while moving between lines,
where the affected numbers grow and shrink in weight as the line
changes (once you see it, you will know what I mean).
+ line-number-major-tick and line-number-minor-tick do use a bold weight
because they are fixed on the scale. Their colours are also improved
to better complement their intended role (these faces are for Emacs 27
or higher).
+ magit-diff-file-heading-selection, magit-diff-hunk-heading-selection
use more appropriate colour combinations.
+ markdown blockquotes and org quote blocks use a different foreground,
which is colder than the previous one. Just to make sure that they
are not mistaken for inline code.
+ message headers use less exaggerated colour combinations. The
differences are fairly minor.
+ message-mml no longer uses a green foreground, as that could
potentially cause confusion with quoted text in some cases. A unique,
albeit less saturated, foreground is used instead.
+ message-separator uses a more neutral colour combination, while
retaining its overall uniqueness within its context (i.e. mail
composition).
+ modeline colours are refined to improve the contrast between active
and inactive states.
+ mu4e-replied-face has a new colour that accounts for colour distance
relative to its context. Thanks to Shreyas Ragavan for reporting the
issue: <https://gitlab.com/protesilaos/modus-themes/-/issues/69>.
+ org agenda date and structure no longer behave like headings in other
Org buffers. Instead, they have their own styles to better perform
their intended function and to avoid exaggerations.
+ org agenda dimmed to-do items (which have blocked sub-items) are no
longer assigned a subtle grey background colour. They are instead
rendered with a bold weight and a subtle grey foreground to minimise
distractions. Thanks to Roman Rudakov for reporting this in issue
101: <https://gitlab.com/protesilaos/modus-themes/-/issues/101>.
+ org agenda clocked items are configured to extend their background to
the edge of the window. Otherwise they are cut off at the last text
character, which creates inconsistencies while using tags: a tag is
placed to the right so the background extends further than without
them. Based again on the feedback of Roman Rudakov in issue 101:
<https://gitlab.com/protesilaos/modus-themes/-/issues/101>.
+ org agenda current time no longer uses a background. A bold weight
and a blue foreground are applied instead. The intent is to keep
things clean. This is also covered by Roman Rudakov's feedback in
issue 101: <https://gitlab.com/protesilaos/modus-themes/-/issues/101>.
+ org-checkbox-statistics-done, org-checkbox-statistics-todo inherit
from org-done and org-todo respectively, instead of defining their own
properties.
+ org drawers and their data now use 'fixed-pitch' in the interest of
consistency with other metadata-like faces. Thanks (yet again!) to
Nicolas De Jaeghere for reporting the issue:
<https://gitlab.com/protesilaos/modus-themes/-/issues/91>.
+ org-footnote underlines will now always use the same colour, instead
of applying the one of other coloured constructs (e.g. when the
footnote is inline and part of the text is rendered as verbatim).
+ org-meta-line is less prominent and, thus, more consistent with other
metadata-related constructs.
+ org-roam faces are updated to match the current state of the upstream
project. The main colour of org-roam links is now different than that
of standard links in an attempt to differentiate between the two (due
to their unique semantics). If this is not desired, you can evaluate
the following:
(setq org-roam-link-use-custom-faces nil)
+ org-todo, org-done, as well as relevant faces such as priorities and
statistics are reviewed to work better with all heading combinations.
Though please read the next section about "adaptive headings", as such
workarounds will no longer be necessary for future stable releases of
Org.
+ selectrum uses different styles than before to account for its unique
property of overlaying matching characters on top of the current
line's background. We want to avoid scenaria where matches are
difficult to discern and the current line is not clear.
+ vc modeline states benefit from improved colour choices. Just minor
adjustments to account for the review of the base modeline colours.
+ vterm base colours now are variants of gray to ensure that some tools,
such as zsh suggestions work properly. Thanks to user "jixiuf" for
reporting this issue and suggesting a possible solution:
<https://gitlab.com/protesilaos/modus-themes/-/issues/93>.
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
=============
+ Belatedly (by about 2 weeks) pushed tag for version 0.12.0. Thanks to
Alex Griffin for bringing this to my attention:
<https://gitlab.com/protesilaos/modus-themes/-/issues/89>
+ Fixed a bug with how some older customisation options were declared as
obsolete. Thanks to Tassilo Horn for noticing and reporting the
problem: <https://gitlab.com/protesilaos/modus-themes/-/issues/88>.
+ Fixed a misplaced optional prefix argument in the manual for how to
switch themes using a custom function. Thanks to Manuel Uberti for
catching this omission of mine and reporting it:
<https://gitlab.com/protesilaos/modus-themes/-/issues/84>.
+ Silenced the Elisp package linter for a spurious error on a single
eldoc face. Thanks to Steve Purcell for the guidance:
<https://github.com/purcell/package-lint/issues/187>.
+ Defined two new dedicated background colours for exceptional cases.
These are intended for internal use in very special circumstances.
+ Reword GuixSD to "Guix System" in the list of package formats
currently available.
+ Reviewed the main blue colours for both themes. While the changes are
practically impossible to discern upon first sight, the process was
far from straightforward. A complete report documents the minutia:
<https://protesilaos.com/codelog/2020-09-14-modus-themes-review-blues/>.
+ Reviewed the "active" palette subset, typically used in the modelines.
No report was necessary for those, as the changes were fairly simple.
+ Reviewed the "intense" background colour that comes into effect when
users opt for the customisation option for intense paren-match styles
(check the manual). Both the hue and the saturation have been changed
to better conform with the intended function of this particular entry.
+ Reviewed the fringe-specific accented backgrounds. Commit 7316e3320
contains tables that compare the relative luminance of old and new
values.
+ Improved the advice for setting fonts using 'set-face-attribute'. The
information is in the manual and is also available as a blog entry:
<https://protesilaos.com/codelog/2020-09-05-emacs-note-mixed-font-heights/>.
+ Rewrote an expression as "(or x y)" instead of "(if x x y)" in one
place. Just goes to show that tweaking the code is also part of the
deal.
+ Abstracted and simplified heading level properties by using bespoke
theme faces. Makes it easier to keep things consistent across the
various face groups.
+ Same principle as above for diff-related styles.
+ Users who prefer to do things their own way or who just wish to
contribute code to the Modus themes may wish to read my "Notes for
aspiring Emacs theme developers":
<https://protesilaos.com/codelog/2020-08-28-notes-emacs-theme-devs/>.
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!
#+end_src
* 0.12.0
:PROPERTIES:
:CUSTOM_ID: h:9d9394c1-84b6-4c23-8936-fe4f2f43301d
:END:
#+begin_src text
Modus Operandi and Modus Vivendi version 0.12.0
By Protesilaos Stavrou <info@protesilaos.com> on 2020-08-26
This entry documents the set of changes since version 0.11.0
(2020-07-31). There have been around 70 commits in the meatime, though
the sheer number may obfuscate the fact that a lot of work has gone into
this release.
As always, every change described here conforms with the accessibility
objective of the themes for a minimum 7:1 contrast ratio between
background and foreground values in their given combinations
(conformance with the WCAG AAA standard).
New customisation options
=========================
1 Completion Frameworks
-----------------------
The star of the show has to be the new option that refashions the
aesthetics of completion UIs: Helm, Icomplete, Ido, Ivy, Sallet,
Selectrum. The 'modus-operandi-theme-completions' and
'modus-vivendi-theme-completions' accept the following symbols:
+ nil (default)
+ moderate
+ opinionated
Nil means that the overall presentation of the UI follows the patterns
established by its own source code. For example, Ivy uses four distinct
background and foreground combinations of accented colours to highlight
the matching groups. A grey background is added to denote the implicit
match between those groups. So we choose to respect this metaphor,
while applying colours that conform with the accessibility goal of our
project. Whereas Icomplete or Ido use subtle styles to present their
results. Again, we remain faithful to their presentation.
With 'moderate', we apply nuanced background and foreground combinations
of accented colour values. This will slightly tone down Helm, Ivy,
Sallet, Selectrum, while it will slightly adjust the looks of Icomplete
and Ido.
Whereas 'opinionated' has a more pronounced effect on the overall
aesthetics of the UI. For the likes of Icomplete and Ido which are
subtle by default, this option will use intense combinations of
background and foreground colours. They are the diametric opposite of
the nil value. Whereas Helm, Ivy, Sallet, Selectrum, will use even more
subtle colours. Again, they are farther away than their default looks.
These new options supersede the now-deprecated and more limited in scope
variables of prior releases:
+ modus-operandi-theme-intense-standard-completions
+ modus-vivendi-theme-intense-standard-completions
Thanks to the following people for their valuable feedback in issue 75:
https://gitlab.com/protesilaos/modus-themes/-/issues/75
+ Anders Johansson
+ Manuel Uberti
+ Shreyas Ragavan
2 Prompts
---------
The 'modus-operandi-theme-prompts' and modus-vivendi-theme-prompts' will
change the overall looks of minibuffer and shell prompts ('M-x shell' as
well as 'M-x eshell'). Their possible values are:
+ nil (default)
+ subtle
+ intense
Nil will only use a coloured foreground for the prompts' text. Simple
and effective.
With 'subtle', the default foreground value is retained but is now
complemented by an appropriately tinted background. The effect is more
noticeable than the default, though not by much.
While 'intense' applies a coloured background and foreground combination
that should clearly stand out from the rest of the context.
Thanks to Manuel Uberti for sharing feedback in issue 74:
https://gitlab.com/protesilaos/modus-themes/-/issues/74
3 Fringe visibility
-------------------
A new pair of symbols supersedes older variables:
+ modus-operandi-theme-visible-fringes ==> modus-operandi-theme-fringes
+ modus-vivendi-theme-visible-fringes ==> modus-vivendi-theme-fringes
While the deprecated options were booleans, the current ones offer a
choice between the following:
+ nil (default)
+ subtle
+ intense
Nil means that the fringes have no distinct background of their own.
They still exist per the settings of 'fringe-mode', but can only be
discerned by tracking the negative space between the frame's or window's
edge and the buffer's effective boundaries.
The 'subtle' value will apply a greyscale background that is fairly
close to the default main background (pure white/black). The fringes
are now visible.
As its name implies, 'intense' has a more pronounced effect than the
other values. It also uses a greyscale background.
Review of already supported faces and colours
=============================================
1 Magit blame styles
--------------------
The headers that Magit's blame interface produces were difficult to tell
apart from their context. A set of carefully selected colours now makes
sure that they are always distinct. Some subtle background values are
used, in addition to other typographic elements.
Thanks to Damien Cassou for reporting this problem and for providing
valuable feedback that informed the final design. Refer to issue 71:
https://gitlab.com/protesilaos/modus-themes/-/issues/71
2 Paren match colours
---------------------
The face that highlights the matching delimiter when 'show-paren-mode'
(or equivalent) is enabled uses two dedicated colours, whose names are:
'bg-paren-match' and 'bg-paren-match-intense'. Those have been reviewed
to make them more obvious in various contexts and to improve their
overall consistency.
A report with relative contrast ratios is available on my website:
https://protesilaos.com/codelog/2020-08-09-modus-themes-paren-match/
I benefited from valuable feedback from Shreyas Ragavan in issue 70:
https://gitlab.com/protesilaos/modus-themes/-/issues/70
3 Mu4e faces
------------
Some faces were tweaked to make it easier to distinguish replied,
forwarded, and draft messages from other headers. The changes are
fairly small in scope, but the effect should be that of an overall
improvement.
Thanks to Shreyas Ragavan for noticing these inconsistencies and for
their continued participation in addressing them. See issue 69:
https://gitlab.com/protesilaos/modus-themes/-/issues/69
4 Notmuch message headings
--------------------------
A couple of inconsistencies with how notmuch would style email addresses
and folded messages were addressed. The generic 'italic' face was also
tweaked in the process, removing the foreground it would falsely define.
Thanks to Damien Cassou for bringing these to my attention in issue 72:
https://gitlab.com/protesilaos/modus-themes/-/issues/72
5 hl-todo
---------
Let the special keywords of 'hl-todo-mode' use an optional slant, just
like code comments do. This is to ensure that they feel part of their
context.
6 Magit general interface
-------------------------
Several faces were reviewed in the interest of colour harmony and to
address potential inconsistencies or exaggerations. The most noticeable
change pertains to the log views, as we now use fewer accent values,
reducing whatever unnecessary "rainbow effect" may have existed.
7 VC commit logs
----------------
The presentation of 'vc-print-log' and 'vc-print-root-log' has been
reviewed to reduce the stark contrast between the colours it once used.
While the elements remain distinct, the differences between them are
more subtle, which is preferable when viewing long lists of
similar-looking patterns.
8 Powerline
-----------
The active and inactive minibuffers now use appropriate accented
backgrounds or foregrounds for some of their elements. This makes them
better for their intended function.
Thanks to Shreyas Ragavan and tycho garen for their feedback in issue
73, which was actually about adding support for Spaceline. It uses
Powerline as its dependency, so we eventually had to accommodate both of
them: https://gitlab.com/protesilaos/modus-themes/-/issues/73
Shreyas also helped by adding a short note in the README which informs
users of those two packages on how to tweak things when conducting tests
or changing themes. See merge requests 9 and 10:
+ https://gitlab.com/protesilaos/modus-themes/-/merge_requests/9
+ https://gitlab.com/protesilaos/modus-themes/-/merge_requests/10
9 Latex sectioning
------------------
The themes will no longer affect the height of the Latex sectioning
faces. This is because there already exists a variable that scales them
accordingly.
Thanks to Anders Johansson for providing insights in issue 77:
https://gitlab.com/protesilaos/modus-themes/-/issues/77
10 Transient pop-up menu
------------------------
Extended support for its new colour-coded faces that follow in the
footsteps of the 'hydra' package for visual semantics.
11 Miscellaneous
----------------
The following faces were refined:
+ 'org-formula' inherits from 'fixed-pitch' to ensure that it does not
break table layouts when the user opts for a mixed-font setup (such as
with 'M-x variable-pitch-mode').
+ 'bongo-elapsed-track-part' uses a more appropriate accented
background.
+ 'symbol-overlay-default-face' is less intense than before. This is in
response to feedback I received from Manuel Uberti as an aside in
issue 75: https://gitlab.com/protesilaos/modus-themes/-/issues/75
+ 'rectangle-preview' uses a slightly accented background, which
distinguishes it from the highlighted region. This is to denote a
different state where the user is typing in some text.
+ 'diff-hl-change' now uses the more appropriate yellow colour instead
of blue. Yellow denotes "mixed changes" and, therefore, stands
between "removed" (red) and "added" (green). As it so happens, yellow
is a colour that derives by mixing red with green.
New packages
============
The following are now explicitly supported by the themes:
+ org-table-sticky-header
+ pkgbuild-mode
+ semantic
+ spaceline
More faces or face groups that are defined:
+ git-rebase (magit)
+ doom-modeline-debug-visual
+ file-name-shadow
+ the faces used by Emacs 27's 'display-line-numbers-major-tick' and
'display-line-numbers-minor-tick'
+ table-cell
Final notes
===========
There now exists an HTML version of the README, which will hopefully
make things easier for users: https://protesilaos.com/emacs/modus-themes/
Other changes are not user-facing. For example, using 'pcase' instead
of 'cond' to make relevant expressions more succinct. Or defining a
coloured underline in a more straightforward way. No need to document
them at length.
While this release introduces customisation options, it feels as though
the themes are approaching a stable state. We know what works, we have
a comprehensive colour palette that can meet our evolving needs, and we
have already achieved broad package/face coverage. All while conforming
with the overarching objective of this project for a minimum 7:1
contrast ratio between background and foreground values in any given
combination we specify.
I wish to thank everyone who has helped me by testing things and sharing
their thoughts. The people already mentioned herein:
- Anders Johansson (https://gitlab.com/andersjohansson)
- Damien Cassou (https://gitlab.com/DamienCassou)
- Manuel Uberti (https://gitlab.com/muberti)
- Shreyas Ragavan (https://gitlab.com/shrysr)
- tycho garen (https://gitlab.com/tychoish)
#+end_src
* 0.11.0
:PROPERTIES:
:CUSTOM_ID: h:7a453154-3486-45a8-9249-9183ad49ff42
:END:
#+begin_src text
Modus Operandi and Modus Vivendi version 0.11.0
By Protesilaos Stavrou <info@protesilaos.com> on 2020-07-31
This entry records the changes since version 0.10.0 (2020-06-24). The
present release covers close to 100 commits, some of which introduce
far-reaching changes. It is not just the quantity that matters.
Sometimes even a minor tweak requires lots of testing and forethought.
This release represents another month of intense work and attention to
detail.
Palette review of "nuanced" colours
===================================
The themes contain a subset of palette variables that have a two-fold
utility:
1. Provide a subtle coloured background that can be combined with all
foreground colours that are intended for text/code highlighting.
2. Produce variegated text in cases where complementary information
needs to be displayed alongside some more prominent construct
(e.g. Org table formulas).
In early July 2020, these colours went through a comprehensive review to
improve their intended use. The complete report is available on my
website:
<https://protesilaos.com/codelog/2020-07-08-modus-themes-nuanced-colours/>
This formed the preparatory work that enabled several of the changes
documented herein, most noticeable among which is the "Org blocks"
customisation option.
Customisation options
=====================
Org blocks
----------
1. The symbols 'modus-operandi-theme-distinct-org-blocks' and
'modus-vivendi-theme-distinct-org-blocks' are DEPRECATED. They are
now REPLACED by the general-purpose 'modus-operandi-theme-org-blocks'
and 'modus-vivendi-theme-org-blocks' respectively.
2. The aforementioned new symbols allow users to configure different
styles for Org blocks.
+ Option 'greyscale' (which you must quote like this: 'greyscale)
will apply a subtle grey background to the contents of the block,
while it will extend its beginning and end lines to ensure that the
area is distinct from the rest of the buffer. This is the style
you would normally get with the old customisation options.
+ Option 'rainbow' (again, must be quoted) will instead apply a
colour-coded subtle background in the main area of the block. The
exact colour depends on the programming language being used. You
would need to check the source code for how these are currently
mapped (search for "org-src-block-faces"). The basic idea is to
have different colours that make it easier for mixing the
input/output of multiple programming languages. Users who engage
in literate programming may find this particularly useful. Because
the block is already quite apparent, the beginning and end lines
are not extended to the edge of the window, to avoid exaggerations
that could create distractions.
Variable pitch headings (proportionately-spaced headings)
---------------------------------------------------------
The symbols 'modus-operandi-theme-proportional-fonts' and
'modus-vivendi-theme-proportional-fonts' are DEPRECATED. They are now
REPLACED by the more appropriately-named
'modus-operandi-theme-variable-pitch-headings' and
'modus-vivendi-theme-variable-pitch-headings' respectively.
The intended effect is exactly the same as before, namely, to let
headings in Org and relevant modes use a proportionately-spaced font
regardless of what the default is (typically a monospaced typeface).
Remember that to configure the exact font family for the generic
'variable-pitch' face, you can use something like this:
(set-face-attribute 'variable-pitch nil :family "FiraGO")
Check the README for further details on setting and mixing fonts.
Faint syntax for programming
----------------------------
Users can now enable 'modus-operandi-theme-faint-syntax' or
'modus-vivendi-theme-faint-syntax'. The intended effect is to tone down
all syntax highlighting in programming modes, while always respecting
the overarching objective of these themes for a minimum contrast ratio
of 7:1 (highest accessibility standard for colour contrast---WCAG AAA).
The default is to use more saturated colours.
Intense hl-line
---------------
Toggling on 'modus-operandi-theme-intense-hl-line' or
'modus-vivendi-theme-intense-hl-line' will apply a more pronounced grey
to the background of faces that highlight the current line. This
affects tools such as the built-in 'hl-line-mode', which is in turn
enabled automatically by lots of other packages, like 'elfeed' and
'mu4e'.
The default is to use a subtle grey.
Intense paren-match
-------------------
Same principle as above. 'modus-operandi-theme-intense-paren-match' and
'modus-vivendi-theme-intense-paren-match' will make the matching
parentheses more intense than the default subtle warm background. This
concerns modes such as that of the 'smartparens' package as well as the
built-in 'show-paren-mode'.
Refactored the use of bold
==========================
A major review of the themes now makes it possible to specify the exact
weight of what a "bold" typeface is. This is only meaningful for cases
where a font family has variants such as "semibold".
Evaluate this, replacing "semibold" with the one your typeface supports:
(set-face-attribute 'bold nil :weight 'semibold)
The default is to use a standard bold weight.
Packages and face groups
========================
Refine already-supported faces
------------------------------
+ The following packages now use more appropriate colour combinations:
- diary
- annotate
- transient (magit pop-up menu, though also used elsewhere)
- fountain
- calendar
- mu4e
- markdown-mode
- outline-minor-faces
+ Other changes:
- org-agenda has undergone a thoroughgoing review to improve the
semantics of colour for scheduled tasks, deadlines, modeline
filters, current date etc.
- org and outline-mode headings have been refined to look better with
the "rainbow headings" option that was introduced in an earlier
release (check the README).
- org-quote now works properly with the "Org blocks" option mentioned
above.
- org-checkbox-statistics uses the same foreground colour as org-todo,
for the sake of consistency.
- org-date now always inherits from 'fixed-pitch', to ensure proper
alignment of elements when a mixed fonts setup is used (tools for
achieving this effect are documented at length in the README). The
relevant patch was contributed by Matthew Stevenson.
- org-meta-line no longer looks like a comment, which helps denote its
special utility (e.g. when evaluating a table's formula).
- org-warning now uses a variant of red for its text, which works
better in the contexts this face is used (e.g. the agenda or the
export dispatcher).
- We now apply a slightly more accented colour combination for
'secondary-selection', which is chiefly used by Org and Calendar in
various contexts.
- Gnus group level faces make more considerate use of colour to better
denote their significance.
- Cited text in message buffers has a better sequence of colours.
- Two new Helm faces are supported.
- Let 'keycast' use a different border colour when the "3D modeline"
option is enabled (refer to the README for that option).
- Extend 'hl-todo-keyword-faces' with the "bug" keyword.
- More intense colour for 'diff-hl-reverted-hunk-highlight'.
- Tone down the focused modeline's border colour.
- Define new bespoke faces that the themes use internally.
- Use more appropriate colours for 'header-line-highlight'.
- Apply greyscale line highlight for flycheck current line in the
diagnostics buffer, instead of the warmer colour combination it had
before.
- Tweak text colour difference between MU4E read and unread messages.
Added support for new packages
------------------------------
+ bongo
+ boon
+ dictionary
+ eshell-fringe-status
+ eshell-git-prompt
+ eshell-prompt-extras
+ highlight-tail
+ hl-defined
+ notmuch
+ tty-menu
Miscellaneous
=============
+ Expand the README with new documentation and clarify parts of the
existing one.
+ Update the Wiki page with screenshots and their descriptions (this in
itself is a day's worth of work):
https://gitlab.com/protesilaos/modus-themes/-/wikis/Screenshots
+ Make the source code of each theme work better with the built-in
'outline-minor-mode'. Check my video if you need a demo on how I use
this in tandem with 'imenu':
https://protesilaos.com/codelog/2020-07-20-emacs-outline-imenu/
Thanks to, in no particular order:
+ Shreyas Ragavan (https://gitlab.com/shrysr) for introducing me to the
idea that derived the "rainbow" Org blocks and for providing valuable
feedback in several issues.
+ Matthew Stevenson (https://gitlab.com/matth0204) for contributing the
aforementioned patch for the 'org-date' face.
+ Manuel Uberti (https://gitlab.com/muberti) for offering valuable
feedback in a number of issues (and special thanks for doing this for
several months now).
+ Dinko (https://gitlab.com/dinkonin) for noticing a not-so-obvious bug
in the initial implementation of the "rainbow Org blocks" option.
+ okamsn (https://gitlab.com/okamsn) for providing the necessary
feedback that allowed me to refactor the use of "bold", mentioned
above.
Refer to the issue tracker (or commit log) for further details:
https://gitlab.com/protesilaos/modus-themes/-/issues
#+end_src
* 0.10.0
:PROPERTIES:
:CUSTOM_ID: h:de114a53-7cbd-49aa-bf24-d1f1f0bf342e
:END:
#+begin_src text
Modus Operandi and Modus Vivendi version 0.10.0
By Protesilaos Stavrou <info@protesilaos.com> on 2020-06-24
This entry records the changes since version 0.9.0 (2020-06-03). The
present release is focused on stability and internal improvements.
Fixes and adjustments
---------------------
Basil L. Contovounesios, aka @basil-conto, (and also a contributor to
core Emacs) sent several patches that do the following:
+ Fix top-level parentheses so that the results of
'custom-theme-set-faces' and 'custom-theme-set-variables' are not
passed as arguments to the first 'custom-theme-set-faces'.
+ Fix the docstrings of the custom 'modus-theme-*' faces.
+ Simplify the syntax of properties assigned to each face.
+ Improve the way styles are inherited by Dired and Ibuffer.
Basil also pointed out an inconsistency with regard to an unwanted
underline effect for the 'doom-modeline-urgent' face in Modus Vivendi.
It was promptly removed.
From my part, I fixed issues 46 and 51 that concerned the way the
compiler would evaluate each theme's palette. The palette is now
defined as a constant. Further information:
- https://gitlab.com/protesilaos/modus-themes/-/issues/46
- https://gitlab.com/protesilaos/modus-themes/-/issues/51
Improvements to existing faces
------------------------------
André Alexandre Gomes (@aadcg) provided valuable feedback and
suggestions in issue 50 on the redesign of several 'org-mode' faces.
The thread is long and contains lots of screenshots:
https://gitlab.com/protesilaos/modus-themes/-/issues/50
The changes in outline:
+ Org checkboxes have a subtle background which gives them a more
pronounced appearance while retaining their overall simplicity.
+ Org dates use a more saturated variant of cyan than they did before.
It helps distinguish them from their context. Especially true for
dates inside of tables.
+ Org agenda dates have also undergone a slight review to match the
above.
+ Org time grid now uses a more appropriate foreground colour, which has
been designed specifically for unfocused context.
+ Org todo keywords use a more semantically-correct variant of red,
rather than the purple one they had before.
+ Org statistics' cookies for pending tasks use a red variant as well
rather than the previous yellow one, in the interest of consistency
and to avoid exaggerations.
Other internal refinements
--------------------------
+ Subtle review of the Modus Vivendi palette. In short, it addresses:
- Imbalanced levels of luminance and inconsistent differences in hue
between them and their neighbouring colours (e.g. the greens between
them, and the greens next to the yellows in the context of syntax
highlighting). The result was that they would create an undesirable
emphatic 'pop out' effect when placed close to more moderate
colours.
- Differences in luminance and hue could lead to scenaria where two
colours could be conflated with each other or otherwise fail to
perform their intended function.
- The complete report is on my website:
https://protesilaos.com/codelog/2020-06-13-modus-vivendi-palette-review/
+ Major review of the 'diredfl' faces, in the interest of improved
readability and harmony between the various colours. This benefits
from the palette changes in Modus Vivendi, but also from a similar
review to Modus Operandi that was documented in version 0.9.0.
+ Refactor the names of dedicates colours for "marking" purposes. These
are used in Dired, Ibuffer, Proced, etc. Then apply them consistently
throughout each theme.
+ Make sure that 'stripes' uses the same colours as 'hl-line-mode'.
+ Let symlinks use a more appropriate colour in Dired and Trashed.
+ Refine the use of colour in 'magit-tag', 'eshell-prompt',
'message-header-name', 'log-edit-header', 'change-log-function',
'message-mml', 'message-header-name', 'message-separator'. These are
subtle (i.e. difficult) tweaks that improve the overall presentation
in context.
+ Make diff indicators not use an unnecessary background when the
user-facing option for "subtle diffs" is enabled (check the README for
the exact name of this option). This ensures consistency between the
indicators and the actual scope of the diffs.
+ Add support for the 'minibuffer-line' package and extend existing
support of the faces used in the built-in Emacs info pages.
My thanks to Basil and André for their contributions!
#+end_src
* 0.9.0
:PROPERTIES:
:CUSTOM_ID: h:96ccc8b9-2d5e-4857-bf25-4e094e17bfed
:END:
#+begin_src text
Modus Operandi and Modus Vivendi version 0.9.0
By Protesilaos Stavrou <info@protesilaos.com> on 2020-06-03
This entry records the changes since version 0.8.0 (2020-04-28). The
present release contains about 50 commits, covering a month of active
development.
All changes are aligned with the primary objective of this project,
which is conformance with the WCAG AAA accessibility standard for colour
contrast. This translates to a minimum contrast ratio of 7:1 between a
given combination of foreground and background colours. The highest
standard of its kind.
All customisation options that are booleans are off ('nil') by default.
The project's policy is to offer such features on an "opt-in" basis,
while always respecting the principle of least surprise.
Refer to the README for further information on the exact names of
symbols and the like.
New customisation options
-------------------------
+ It is now possible to make the faces of Icomplete, Ido, and a few
other related tools such as 'orderless', use coloured backgrounds to
style their feedback. This is the aesthetic already in effect for
Ivy, Helm, and Selectrum. The default is more subtle, in that it uses
just an accented foreground value without any added background.
+ Advanced users can now override both the exact values of colour
variables, as well as the mapping of properties/variables to faces.
In practice this means that it is possible to completely change parts
of the theme (or the entirety of it for that matter). It also means
that users can simply access the theme's palette for the sake of
correctly passing the appropriate value to some bespoke face of
theirs.
+ An extra increment for scaled headings is now available. This should
hold the highest value on the scale. Such variables only take effect
when the user opts for the "scaled headings" option.
Overview of changes
-------------------
+ A set of internal reforms were carried through in order to allow the
colour palette to be accessed from user configuration files. This
required a lot of debugging work to make sure the themes compile
properly and performance is not affected.
- The original idea for this redesign was suggested by Len Trigg in
issue 39: https://gitlab.com/protesilaos/modus-themes/-/issues/39.
Len also provided a real-world implementation of this new option,
which is included in the project's README.
- André Alexandre Gomes helped figure out the problems caused by the
initial design of this feature. In particular, André identified a
performance penalty as well as errors pertaining to byte
compilation. Everything was eventually resolved. For more see
issue 44: https://gitlab.com/protesilaos/modus-themes/-/issues/44.
+ Several org-mode faces were reviewed in order to cope well with mixed
font settings. This is about use-cases where the main typeface is
proportionately-spaced, either by default or by some minor mode like
the built-in 'variable-pitch-mode'. The intent of configuring those
faces is to make them always inherit a fixed-pitch (monospace) font
family, in the interest of preserving the alignment of elements. The
idea, suggested code, as well as user feedback were offered by Ben in
issue 40: https://gitlab.com/protesilaos/modus-themes/-/issues/40.
+ Mixed font settings may have some side-effects depending on user
configurations. This is unavoidable as we cannot control how users
define their fonts. Mark Barton reported one such case, while he was
able to fix it by making use of the suggested typeface definitions.
See issue 42: https://gitlab.com/protesilaos/modus-themes/-/issues/42.
+ The faces for the 'tab-bar-mode' and 'tab-line-mode' that ship with
Emacs 27 were written anew. Same for those of 'centaur-tabs'. The
ideas for the redesign as well as the overall aesthetic are Ben's, per
issue 41: https://gitlab.com/protesilaos/modus-themes/-/issues/41.
+ An edge case with Helm's interpretation of colour values for its
ripgrep interface was reported by Manuel Uberti in issue 49:
https://gitlab.com/protesilaos/modus-themes/-/issues/49. It
essentially had to do with the syntax for the regexp engine as read by
the underlying 'rg' executable. Collaboration on that front
eventually led to fixes in Helm itself, committed by its maintainer.
Note that the README for the Modus themes already contains information
on how Helm applies a face to the matches of grep or grep-like
commands. Issue 49 confirmed what was already known in that regard
(i.e. that the "--color=never" command-line option is required to use
the Helm face, else a colour value from the ANSI colour vector is
used---both are supported by the themes).
+ The faces for Flycheck, Flymake, and Flyspell that would apply an
underline effect were completely rewritten to account for relevant
differences between GUI and TUI Emacs.
- For GUI Emacs, all affected faces will now just use a colour-coded
wavy underline. Empowered by the introduction of dedicated
linter-related colours in prior commits (for version 0.8.0), we no
longer have to change the foreground value of the offending text in
addition to applying the underline effect. Whereas before the text
would also get repainted, which was too intrusive in most
circumstances.
- If support for wavy underlines is not available, we assume the
presence of a TUI, which generally is relatively more limited in its
ability to reproduce colours with precision (meaning that the
dedicated linter colour could be distorted, potentially producing
inaccessible combinations). So for those cases we apply a straight
underline combined with a colour-coded foreground for the affected
text. This makes it more intense compared to the GUI equivalent,
but is the necessary course of action to overcome the constraints
imposed by the underlying terminal.
+ The palette of Modus Operandi underwent lots of subtle changes to make
the background value of hl-line-mode more visible while retaining the
overall style and character of the theme. In principle, you should
not be able to tell the difference, unless presented with a careful
side-by-side comparison. This is the comprehensive report, including
a reproducible org-mode document with all the relevant contrast ratios:
https://protesilaos.com/codelog/2020-05-10-modus-operandi-palette-review/.
+ Fixed `org-hide' to actually "hide" by using the appropriate colour
value.
+ Several other face groups received minor tweaks.
+ The README was improved to better present the available customisation
options and to cover other topics of interest.
+ Updated the screen shots and their description in the relevant Wiki
page: https://gitlab.com/protesilaos/modus-themes/-/wikis/Screenshots.
Added support for
-----------------
+ circe
+ el-search
+ eros
+ golden-ratio-scroll-screen
+ highlight-indentation
+ hyperlist
+ indium
+ journalctl-mode
+ minimap
+ nxml-mode
+ vdiff
+ yasnippet
#+end_src
* 0.8.0
:PROPERTIES:
:CUSTOM_ID: h:afa34aec-7079-4c45-8e16-ab4e7cc8cd6a
:END:
#+begin_src text
Modus Operandi and Modus Vivendi version 0.8.0
By Protesilaos Stavrou <info@protesilaos.com> on 2020-04-28
This entry records the changes since version 0.7.0 (2020-03-30). The
present release contains a little more than a hundred commits, covering
one month of intense work.
All changes are aligned with the primary objective of this project,
which is conformance with the WCAG AAA accessibility standard for colour
contrast. This translates to a minimum contrast ratio of 7:1 between a
given combination of foreground and background colours.
All customisation options mentioned herein are off ('nil') by default.
The project's policy is to offer such features on an "opt-in" basis,
while always respecting the principle of least surprise.
Refer to the README for further information.
Four new customisation options
------------------------------
The options in outline, with their detailed description below:
+ Rainbow headings
+ Section headings
+ 3D modeline
+ Subtle diffs
1. "Rainbow headings" will apply more vivid colours to headings in
'org-mode' and 'outline-mode'. The gradation is similar to that of a
rainbow's colour spectrum.
The default is to use colour values that are closer to the grey
scale.
2. "Section headings" also apply to 'org-mode' and 'outline-mode'. They
will draw an overline over each heading and use a nuanced background
colour that is appropriate for each level. For Org, this option has
some additional effects, where it will render keywords and priority
cookies in a box and add to them a subtle background. This is to
make sure that everything feels consistent (to the extent possible).
The default is to not use overlines, backgrounds, boxes in any of the
relevant faces. This is consistent with the standard austere
colouration of headings: to not deviate too much from a "plain text"
aesthetic.
NOTE: "rainbow headings" and "section headings" can work on their own or
be combined together.
3. "3D modeline" will use a faux unpressed button style for the current
window's modeline (like the standard looks of 'emacs -Q'). The
colours used for the active and inactive modelines are tweaked
accordingly to maximise the effect while retaining the visual
distinction between them.
The default is to draw the modelines in a two-dimensional style, with
the active one having a more noticeable border around it.
4. "Subtle diffs" will use colour-coded text for line-wise differences
without applying any appropriately-coded background value or, where
necessary, by using only a subtle greyscale background. This affects
'diff-mode', 'magit', 'ediff', and 'smerge-mode'. For Magit an extra
set of tweaks is implemented to account for the differentiation
between the focused and unfocused diff hunks.
Due to their unique requirements, word-wise or refined changes are
always drawn with a colour-coded background, though it is less
intense when this option is enabled.
The default is to use a colour-coded background and foreground
combination (e.g. light green text on a dark green backdrop) and to
make appropriate adjustments for refined diffs and modes of
interaction such as Magit's focused/unfocused diff states.
Other major refinements
-----------------------
+ Thoroughly revise the colours of 'ediff' and 'smerge-mode', so that
they are aligned with those of 'diff-mode' and 'magit'. This is in
addition to the "subtle diffs" options mentioned in the previous
section.
+ Review the faces used by Flycheck and Flymake. A wavy/curly underline
is now used in all terminals that support it. The underlined text is
drawn with a more nuanced foreground than before. The previous design
was exaggerating an already clear effect and could make things more
difficult under certain circumstances.
+ All language checkers, including the aforementioned linter front-ends,
now benefit from a new set of colours that are designed specifically
for this particular purpose. Makes the affected faces feel more
different than their context.
+ Use dedicated colours for escape sequences, regular expression
constructs, and quoted characters. The goal is to better
differentiate them from their surroundings.
+ Tweak the colours of 'hydra' to improve the distinction between its
various types of behaviour.
+ Reduce the overall luminance of the background colours used in the
fringes by the likes of 'flycheck', 'flymake', 'diff-hl', etc. They
should now not stand out more than they should, while retaining their
intended role.
+ Implement more saturated colours in Elfeed. The previous choices
could make it harder to differentiate the various parts of the
presentation.
+ Make better use of the customisation options for bold and slanted
constructs where that is allowed. If a face is not tied to the
semantics of these styles then it is drawn without them, unless the
user specifically opts for the relevant customisation options.
Added support for packages (A-Z)
--------------------------------
+ ag
+ color-rg
+ ctrlf
+ debbugs
+ eglot
+ forge
+ helpful
+ highlight-symbol
+ ibuffer
+ icomplete
+ iflipb
+ magit-imerge
+ man
+ orderless
+ page-break-lines
+ parrot
+ phi-grep
+ phi-search
+ pomidor
+ rcirc
+ spell-fu
+ switch-window
+ swoop
+ tab-bar-mode
+ tab-line-mode
+ trashed
+ tomatinho
+ tuareg
+ vimish-fold
+ visible-mark
+ vterm
+ wcheck-mode
+ winum
+ woman
Miscellaneous changes and concluding remarks
--------------------------------------------
+ Rewrote large parts of the README to make the customisation options
easier to discover and understand.
+ Updated the screen shots and their description in the relevant Wiki
page: https://gitlab.com/protesilaos/modus-themes/-/wikis/Screenshots
#+end_src
* 0.7.0
:PROPERTIES:
:CUSTOM_ID: h:353114b7-6980-4622-8057-b8cbb8361a8a
:END:
#+begin_src text
Modus Operandi and Modus Vivendi version 0.7.0
By Protesilaos Stavrou <info@protesilaos.com> on 2020-03-30
This entry documents the changes since version 0.6.0 (2020-03-01). The
present release is the largest to date containing 110 commits.
All changes conform with the primary objective of this project, which is
conformance with the WCAG AAA accessibility standard for colour
contrast. This represents a minimum contrast ratio of 7:1 between a
given combination of foreground and background colours.
All customisation options mentioned herein are off ('nil') by default.
The project's policy is to offer such features on an "opt-in" basis.
Refer to the README or each theme's source code for the names of these
user-facing symbols.
Major refinements to existing face groups
-----------------------------------------
+ The headline feature of this release is a refined set of colours for
visualising version-control-system differences ("diffs"). The new
colours are less intense than before and are designed to better convey
the meaning of the constructs they apply to. Affected face groups are
those of 'magit' and 'diff-mode'. A future release will assess how
similar packages, such as 'ediff', can benefit from this work.
+ The other major set of changes concerns the colours that apply to
fringes (see 'fringe-mode'). A new customisation option allows for a
distinct background for the fringes (courtesy of Anders Johansson in
commit 80fb704). The default uses the same colours as the main
buffer's background. Building on this effort, fringe indicators, such
as those of 'flycheck' now benefit from an entirely new set of
background+foreground colour combinations that are designed
specifically for the fringes.
+ A new customisation option allows users to render 'org-mode' source
blocks in a distinct background colour. The default is to use the
same background as the rest of the buffer. When this option is
enabled, the background colour for the beginning and end line of such
blocks is extended to the end of the window (using the ':extend t'
attribute for >= Emacs 27). Older Emacs versions already extend to
the end of the window.
+ The colour combination that shows the matching parentheses or
delimiters has been reviewed. The commit is fairly small and the
changes are immediately noticeable only to the most discerning of
eyes. Still, the considerations informing the review imposed a
rigorous method. Rather than summarise the findings, interested
readers are advised to refer to commit af3a327: it offers a
comprehensive analysis on the matter.
Added support for packages (A-Z)
--------------------------------
+ auctex/tex
+ bm
+ buffer-expose
+ centaur-tabs
+ cider (tentative, feedback is much appreciated)
+ csv-mode
+ dynamic-ruler
+ ebdb
+ elfeed-score
+ flyspell-correct
+ fold-this
+ freeze-it
+ frog-menu
+ git-walktree
+ helm-switch-shell
+ highlight-defined
+ highlight-escape-sequences (hes-mode)
+ highlight-numbers
+ highlight-thing
+ hl-todo
+ ioccur
+ julia
+ kaocha-runner
+ markup-faces (adoc-mode)
+ multiple-cursors
+ num3-mode
+ org-roam
+ org-superstar
+ org-treescope
+ outline-minor-mode
+ paradox
+ rainbow-identifiers
+ rg
+ ripgrep
+ sallet (tentative, feedback is much appreciated)
+ selectrum
+ sesman
+ side-notes
+ skewer-mode
+ stripes
+ symbol-overlay
+ syslog-mode
+ vc-annotate (C-x v g)
+ volatile-highlights
+ web-mode
+ yaml-mode
Note about VC-annotate
----------------------
Quoting from the relevant note in the project's README:
Due to the unique way `vc-annotate' (`C-x v g') applies colours,
support for its background mode (`vc-annotate-background-mode') is
disabled at the theme level.
Normally, such a drastic measure should not belong in a theme:
assuming the user's preferences is bad practice. However, it has
been deemed necessary in the interest of preserving colour contrast
accessibility while still supporting a useful built-in tool.
If there actually is a way to avoid such a course of action, without
prejudice to the accessibility standard of this project, then please
report as much (or contribute as per the information in the
Contributing section).
Overview of refinements to already supported packages
-----------------------------------------------------
In this section the notion of "dedicated colours" pertains to colour
values that are reserved for special faces. They are never used for
syntax highlighting or other common scenaria.
+ Define new background colours for fringe indicators (as noted in the
first section). Apply them to 'bm', 'diff-hl', 'git-gutter',
'flycheck' fringe indicators. All such indicators are now made more
visible and work better with the new customisation option for
rendering the fringes in a distinct background.
+ Define dedicated colours for tab-like interfaces. Currently these
apply only to 'centaur-tabs'. The intention is to eventually
implement them to the tab modes that ship with Emacs 27, as well as
any other package that offers such functionality.
+ Define dedicated colours for actions that "mark" items. Use them in
'dired', 'proced', 'gnus'. An accented background is combined with an
accented foreground. The intention is to make the underlying
construct distinct even under circumstances where the mark's
background changes, such as when it intersects with 'hl-line-mode' or
'stripes': the accented foreground will still be recognisable as a
colour that differs from the main foreground. The use of a bold font
weight further reinforces the intended action.
+ Refine 'dired' faces to account for the new "mark" styles.
Directories are no longer rendered in a bold weight.
+ Tweak the colours used in the built-in 'diary' and 'calendar' for
better usability.
+ Tweak 'deadgrep' colours for consistency with packages that offer
similar functionality.
+ Tweak 'compilation-line-number' in the interest of consistency with
similar interfaces.
+ Use a more appropriate colour for 'trailing-whitespace'. It now is a
colour value that was designed specifically as a background.
+ Expand 'fountain-mode' support by covering its new heading faces. The
headings will be presented in larger font sizes, or using proportional
fonts, should the user enable the relevant theme customisation options
(see README or source code).
+ Remove bold weight from matching parentheses in 'show-paren-mode' and
'smartparens'. The temporarily applied bold weight can cause
misalignments while using certain fonts. Also apply the new colours
for matching delimiters, as documented in the first section.
+ Refine 'outline-mode' colours to be consistent with those of Org's
headings.
+ Several usability and colour refinements for 'helm' and related
packages in that milieu.
+ Remove box property from emphasis markers in the mode line. It
created inconsistencies with other faces.
+ Refine the colours used in Magit logs, `change-log', `log-view'. They
are meant to be more distinct from their context, without drawing too
much attention to themselves.
+ Minor internal fixes for indentation and the like.
Miscellaneous changes and concluding remarks
--------------------------------------------
+ Add section in the README which documents a legal requirement for all
potential non-trivial code contributions: the need to assign copyright
to the Free Software Foundation. The Modus Themes are now distributed
via the official GNU ELPA repository and copyright over them is
assigned to the FSF.
+ Add CHANGELOG file which consolidates all tagged release notes such as
this one.
+ Add new screen shots to the relevant Wiki page, together with detailed
descriptions on what is being demonstrated:
https://gitlab.com/protesilaos/modus-themes/-/wikis/Screenshots
Special thanks to Manuel Uberti for reporting several issues and
offering feedback where appropriate. I was able to add support for lots
of new packages. While a few among the already supported face groups
underwent tweaks and refinements. The 'helm' ecosystem benefited the
most.
Thanks to Anders Johansson for the patch that introduced the
fringes-related customisation option. It inspired me to reconsider the
use of this particular area of the interface, which eventually led to
the barrage of commits that refashioned the fringe indicators. A major
win overall.
Thanks to Jonathan Otsuka for fixing an error of mine on the naming of
some symbols. My apologies for missing it: I will be more careful from
now on.
Note: both patches were small, requiring no copyright assignment.
Larger contributions are always welcome, though make sure you read the
section in the README with regard to assigning copyright to the Free
Software Foundation.
#+end_src
* 0.6.0
:PROPERTIES:
:CUSTOM_ID: h:c8c33ff2-6f75-4642-a27e-ee6e8abc493e
:END:
#+begin_src text
This release contains lots of refinements and additions.
Let me start with an administrative point: I have completed the process
of assigning my copy rights to the Free Software Foundation. This
covers every contribution I make to GNU Emacs. In practice, it means
that the Modus themes can now be included in the official ELPA archive
and theoretically be shipped with Emacs itself. The ELPA inclusion is
ongoing. Once it is completed, I will update the docs accordingly.
The administrative change has no effect on the way this project is
handled. I still am the developer/maintainer and will continue to
improve things further. If you still have questions, feel free to
contact me: https://protesilaos.com/contact
Moving on to the changes since version 0.5.0 (2020-01-26).
Added support for:
+ alert
+ apropos (built-in)
+ dap-mode
+ deft
+ dim-autoload
+ dired-git
+ enhanced-ruby-mode
+ gbd-mi.el (built-in library)
+ helm-ls-git
+ helm-xref
+ imenu-list
+ jira (org-jira)
+ js2-mode
+ jupyter
+ org-pomodoro
+ origami
+ rmail (built-in)
+ vc-print-log (built-in)
+ window-divider-mode (built-in)
+ xref (built-in)
Refinements to existing faces:
+ A new subset of "nuanced" accent colours has been introduced. These
are named {red,green,yellow,blue,magenta,cyan}-nuanced. Their purpose
is to be used in contexts where lots of structured information is
presented to the user, but each component does not need to draw too much
attention to itself (e.g. Org's metadata). As always, their contrast
ratio is designed to always be >= 7:1 relative to the backgrounds they
may be combined with.
+ Greatly improve the support for Gnus, even though most changes are
subtle and are made in the interest of consistency. The group levels
now make use of the "nuanced" palette where appropriate (to denote
levels of lower importance).
+ Several refinements for Org, including the use of "nuanced" colours
for various metadata tags. The agenda headers will now be scaled
appropriately and use a variable-pitch font if the user sets the
relevant customisation values of the theme they are using (check the
documentation in each theme file or the repo's README).
+ Lots of refinements for Helm. Some of these were introduced to align
the overall aesthetic with equivalent metaphors in Ivy. Others are
meant to improve the styles of the headers and make various constructs
consistent with their variants in the Helm ecosystem but also with their
non-Helm counterparts (such as xref file names with and without Helm,
but also with Helm's grep).
+ Improve the colours of buttons in contexts such as M-x customize.
This is especially noticeable in modus-vivendi-theme (the dark theme)
where the buttons are a darker shade of grey rather than the original
lighter one.
+ Keycast now uses styles that are more consistent with the overall
aesthetic of the Modus themes. This means that the mode line indicators
are blue-ish (blue is generally used for highlights in the mode line,
but also when hovering over an item with the mouse pointer). The pseudo
button effect (colours + 3d) has been removed in favour of a flat look,
in line with the flatness of the mode line itself. Whereas before the
keycast faces where designed to be consistent with the package's
defaults.
There were also a few minor refinements for:
+ calendar and diary
+ icomplete
+ mm-uu-extract
+ nobreak-hyphen and nobreak-space
+ org-habit
+ tooltip-mode
Finally, the Commentary section of each theme has been greatly expanded.
It now includes the user-facing customisation options and the complete
list of supported packages.
#+end_src
* 0.5.0
:PROPERTIES:
:CUSTOM_ID: h:dffc2bd4-6597-4be4-88f6-b349be7ebc6e
:END:
#+begin_src text
This release contains support for several new packages and lots of
refinements for existing ones. A lot of work went into making the
themes more robust by reviewing the inheritance of styles from one
face group to another (in general, the ':inherit' property should not
be used frivolously). Several subtle changes were made to the colour
palette of both themes to ensure consistency, enable more possible
combinations, and avoid potential ambiguity under certain potential
circumstances.
Overall, this release gives me confidence that the themes have reached
a fairly stable state. What follows is an overview of the changes
since version 0.4.0 (2020-01-02).
Added support for:
+ equake
+ flymake
+ focus
+ fountain (fountain-mode)
+ git-lens
+ git-timemachine
+ hi-fill-column
+ highlight-blocks
+ info-colors
+ lsp-mode
+ lsp-ui
+ proced (built-in)
+ regexp-builder (built-in)
+ suggest
Refinements:
+ The header line uses its own dedicated colours. Several changes
were made in 'eww', 'info', 'elfeed', 'magit', 'flycheck' to make
sure that any accent value that appears there conforms with the
overarching accessibility objective of the Modus themes (contrast
ratio of >= 7:1, else WCAG AAA).
+ 'ivy' no longer uses a box style for the current line, as that was
not always reliable. Appropriate colours are used instead.
+ 'org-mode' blocks use a foreground value that distinguishes their
opening and closing tags from source code comments.
+ The 'org-ellipsis' face was configured to always inherit the looks
of its respective heading or element, rather than have its own
excessive styling.
+ 'paren-match' has colours that are designed specifically for it.
This is done to retain their utility while making sure they are not
mistaken for some other type of feedback.
+ 'magit' has explicit styles for the mode line process indicators,
instead of inheriting from another face. The intention is to use
foreground values that are designed specifically for use on the mode
line (the minimum contrast ratio requirement).
+ 'erc' faces have been thoroughly reviewed in the interest of better
usability. Its mode line indicators now use appropriate colours.
+ The faces of the 'messages' library have been thoroughly reviewed.
This affects various email interfaces, but also 'elfeed' entry
metadata headings.
+ 'whitespace-mode' no longer has a newline character that stands out.
That kind of emphasis was not necessary, given that the symbol used
is a dollar sign, which is already far more visible than a mid dot.
+ 'font-lock' (generic syntax highlighting) has better colour
combinations for regexp grouping constructs.
+ 'rainbow-delimiters' was given its missing base error face.
+ 'git-commit' comment action uses a slightly different foreground
value than before to better match its context.
+ 'isearch' and 'query-replace' use colours that properly denote each
action's utility.
+ 'visual-regexp' has been reviewed to make the matching groups more
distinct from each other.
+ 'occur' and any other buffer that relies on the 'match' face can now
benefit from the new colour combinations, in that its results cannot
be confused for the active 'isearch' or 'query-replace' or even
their lazily highlighted results (or, indeed, of any other search
tool).
+ 'company' uses faces for its search feedback that are consistent
with other search metaphors.
+ Emacs 27's new ':extend' property is only implemented where
necessary (note that the latest release is version 26.3).
#+end_src
* 0.4.0
:PROPERTIES:
:CUSTOM_ID: h:1597e301-f9df-4aac-8ec5-b8ecf34f2930
:END:
#+begin_src text
This is an overview of the changes since version 0.3.0 (2019-12-25).
Add support for:
+ ert
+ flycheck-indicator
+ mentor
+ mu4e-conversation
+ powerline-evil
+ telephone-line
+ vc (built-in version control)
Refinements to already-supported packages:
+ company-mode (several refinements)
+ doom-modeline (major review)
+ helm (several tweaks)
+ hl-line-mode (use unique background)
+ ivy (improve matching line)
+ line-number-mode (minor tweaks)
+ markdown-mode (comprehensive expansion)
+ mode-line (more appropriate styles for the highlight)
+ powerline (minor tweaks)
+ region (use unique background)
+ swiper (improve matching line in main window)
+ whitespace-mode (several refinements)
+ mu4e (tweak mu4e-modeline-face for consistency)
Miscellaneous:
+ Fix actual and potential problems with cursor faces that would
distort the use of appropriate background and foreground colours.
The documentation stipulates that the `cursor' face cannot be
inherited by other faces, due to its peculiar nature of only
recognising the background colour.
+ Add support for more bold constructs in code. As with all such
options, it is disabled by default, expecting the user to
explicitly opt in.
+ Declare additional custom faces. Only meant for internal use.
+ Subtle refinements to "active" colour values in both Modus
Operandi and Modus Vivendi. These mostly concern the mode line
(with a few special exceptions), where emphasis has been placed on
the need to provide greater contrast between accent values that
can be used there.
+ Minor documentation refinements.
#+end_src
* 0.3.0
:PROPERTIES:
:CUSTOM_ID: h:cb0ca8dc-3960-4490-b3c4-27d10cf6ed44
:END:
#+begin_src text
Overview of changes since 0.2.0 (2019-12-18):
+ Add support for the following packages:
+ apt-sources-list
+ calfw
+ counsel-css
+ counsel-notmuch
+ counsel-org-capture-string
+ cov
+ disk-usage
+ evil-visual-mark-mode
+ geiser
+ keycast
+ org-journal
+ org-noter
+ paren-face
+ powerline
+ vc
+ xah-elisp-mode
+ Explicitly style the following packages (these were already covered,
in terms of the colours they used, but are now targeted directly):
+ calendar
+ counsel
+ cursor
+ package (M-x list-packages)
+ Minor tweaks to face groups:
+ dired
+ compile
+ Fixes and refinements:
+ Documentation strings will now inherit the option for slanted
constructs (off by default -- see the README about all the user
options).
+ Comment delimiters have the same styles as the body of the comment
to avoid inconsistencies when the option for slanted constructs is
enabled.
+ The line number that is displayed in the compile log is now
correctly styled.
+ Removed duplicate entries for ivy-remote and added ivy-separator.
+ Ensure that the minibuffer prompt is always above the minimum
contrast ratio of 7:1, by using a more appropriate shade of cyan.
+ Properly reference a couple of variables in Modus Vivendi.
+ Internal adjustments:
+ Decouple the core dired faces from those of external packages.
+ Same for org and org-recur.
+ Minor documentation updates.
#+end_src
* 0.2.0
:PROPERTIES:
:CUSTOM_ID: h:c9746d04-adf4-41b1-9b7c-6caaf17f8816
:END:
#+begin_src text
Overview of changes since 0.1.0 (2019-12-09):
+ Comprehensive review of `org-mode' faces. The use of colour should
now be more consistent with the semantics of each element. These should
also respond better to a variety of combinations, such as when the user
has `hl-line-mode' enabled. The agenda view is the greatest beneficiary
of this review.
+ Make `mu4e' mode line faces consistent with other elements that may be
placed on the mode line.
+ Make `gnus' header name/subject more distinct.
+ Several minor refinements to `ivy' and its extensions.
+ General usability refinements to `ace-window'.
+ Minor review of `elfeed' styles, in the interest of improving the
contrast between the elements.
+ Add support for:
+ `persp-mode' (fork of the already supported `perspective')
+ `dashboard'
+ `evil-mode'
+ `evil-goggles'
+ `ruler-mode'
#+end_src
* 0.1.0
:PROPERTIES:
:CUSTOM_ID: h:e14e612e-6951-4812-bc88-62c498bd5644
:END:
#+begin_src text
First stable release of Modus Operandi and Modus Vivendi.
#+end_src
Reference in a new issue View git blame Copy permalink