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.
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>.
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.
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).