The contribution was made in pull request 71 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/pull/71>.
The change is small and is below the ~15 line limit. As such, it does
not require copyright assignment to the Free Software Foundation.
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.
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.
Thanks to Andrew Tropin for requesting this feature. We used to
provide this style in earlier versions of the themes. Andrew's
request was done via a private channel and the information is shared
with permission.
I already had the functionality internally, but it is good to expose
it to users. I am inspired to do so after checking Sacha Chua's blog
post "Making highlight-sexp follow modus-themes-toggle".[1] Sacha is
using a private function from the themes, which will be problematic if
I ever move things around.
[1] <https://sachachua.com/blog/2023/01/making-highlight-sexp-follow-modus-themes-toggle/>
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. This was
supported by the fact that the Modus themes are built into Emacs so we
need to accommodate every workflow that Emacs supports.
With this addition, I am reverting to the old way of doing things:
loading a Modus theme should disable all others. Users who need to
run multiple themes can set this option to a nil value.
Thanks to Tony Zorman for the feedback on the mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C874jtew0gp.fsf%40hyperspace%3E#%3C87bkne84d2.fsf@hyperspace%3E>.
This means that a semantic colour mapping in the palette can have as
its value another mapping. The function will find the underlying
colour.
This solves a problem reported by Imran Khan on the mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3Cb7ca4702162fd575593f8ded28d9a888.contact%40imrankhan.live%3E>.
I was aware of it from before the release of version 4.0.0 but I 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.
This was always the intention for all three of
'compilation-{error,info,warning}'. They will use a bold weight when
the user option 'modus-themes-bold-constructs' is non-nil.
Thanks to Manuel Giraud for informing me about the inconsistency in
'compilation-warning'. It was done via a private channel and the
information is shared with permission.
I don't know about you, but I just found my new favourite:
(setq modus-themes-common-palette-overrides
'((mail-cite-0 fg-dim)
(mail-cite-1 fg-alt)
(mail-cite-2 fg-dim)
(mail-cite-3 fg-alt)
(mail-part yellow-cooler)
(mail-recipient green-cooler)
(mail-subject red-cooler)
(mail-other green)))
Try either of those:
(setq modus-themes-common-palette-overrides modus-themes-preset-overrides-faint)
(setq modus-themes-common-palette-overrides modus-themes-preset-overrides-intense)
The user can thus override the 'fringe' mapping to whatever colour
they prefer, instead of us hardcoding it to two shades of gray.
To make the 'fringe' invisible, set it to the main background.
Video tutorial on colour mappings:
<https://protesilaos.com/codelog/2022-12-17-modus-themes-v4-demo/>.
Providing bespoke themes gives us the freedom to implement changes
wherever necessary without making the code more complex. The now
discontinued 'modus-themes-deuteranopia' was a user option with
limited scope: it simply replaced green with blue in some contexts.
But a proper design for deuteranopia requires more than that. These
new themes are the right solution and I am sure the people who need
them will greatly appreciate them.
Prior to this change some user options provided for a 'bold' style
which would apply a heavy typographic weight. Since we have the
mechanism to add an arbitrary font weight, there is no reason to limit
those options to 'bold'.
The user has the option to override the bg-completion colour, which
gives them all they need. I had already deprecated the "intense"
style earlier, though not from the docs.
Version 4 of the modus-themes is abstracting each theme's palette,
introduces semantic colour mappings, and expands the scope of the
palette overrides. I am removing user options, but am actually giving
user more power over how to tweak the theme. Overview:
<https://protesilaos.com/codelog/2022-12-07-modus-themes-4-colour-values-mappings/>.
As this diff demonstrates, we remove a lot of the complexity from the
themes.
The 'modus-themes-custom-auto-reload' is the successor to the
now-deprecated 'modus-themes-inhibit-reload'. The new name is more
descriptive and easier to reason about.
The functionality is now enabled by default. I am using it with
'setopt' (Emacs 29) and think it is a user-friendly feature.
Thanks to Philip Kaludercic for the feedback on the mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87h6y3gyxx.fsf%40posteo.net%3E>.
Philip is the author of the original 'modus-themes-inhibit-reload' and
the relevant setup. I just made some minor tweaks for this "version
4" rewrite of the themes. Any mistakes are my own.
I removed lots of packages to make things work (they were using
colours that I removed). Now that I have a stable basis, I am
bringing some of them back.
I removed earlier in this refactoring process because it was depending
on faces/colours that I have since removed. Now that things are
clear, I can support it again.
I removed earlier in this refactoring process because it was depending
on faces/colours that I have since removed. Now that things are
clear, I will start reintroducing packages.
This harmonises an inconsistency that existed before where those
headings were controlled by another user option. That option is
deprecated in the interest of consistency and simplicity.
The intent is:
* Remove the subtle gray selection line. It is not usable in several
cases.
* Eliminate the distinction between 'selection' and 'popup'. All UIs
now have the same style. This is not a problem in practice as I
have revised the relevant colour values to work in both contexts.
* Remove the 'intense' variant, so as to reduce the number of colour
combinations. The code is simpler and we reduce the special colours
that we would otherwise need to maintain.
Part of this refactoring for version 4.0.0 is to:
* Make the colour palettes smaller and more efficient.
* Introduce a mechanism of semantic colours (colour mappings), which
lets us optimise for each theme and, potentially, introduce new
themes.
* Amplify gray values to improve usability.
* Remove user options of dubious value and, generally, makes things
easier to understand.
I will explain everything on my website as well as the change log,
once version 4.0.0 is released. What I have here is not final and I
am still testing for regressions.
This is based on merge request 44 by Xinglu Chen on the GitLab mirror
from 2021-06-16:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/44>.
That contribution could not be merged, as it exceeded the ~15 line
limit and thus required copyright assignment to the Free Software
Foundation. The author became inactive soon thereafter despite their
stated intention to do the paperwork.
Thanks to Laith Bahodi for informing me about this in issue 48 on the
GitHub mirror: <https://github.com/protesilaos/modus-themes/issues/48>.
In principle, the agda project should be inheriting from font-lock
faces instead of hardcoding their own colour values: those do not play
nicely with themes. If anyone familiar with agda reads this, I
encourage you to work with upstream to make things better for all
themes. Also consider that adga cannot be tested without an
established setup for Haskell, which adds to the burden of maintaining
those faces at the theme level (I could not test them and only went by
screenshots and prior experience).
This was done in pull request 47 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/pull/47>.
The contribution is on a single line and this is Aleksei's first
contribution to this project. It thus does not require copyright
assignment to the Free Software Foundation.
This is to make the export to texinfo output:
@code{nil}
Instead of a generic "nil".
This was already done in most placed, but some had escaped my
attention. I was reminded to check again by commit 0f39eb3, courtesy
of Stefan Kangas.
The previous style did not actually hide the fringes, as olivetti
would still fall back to reading the generic fringe face.
The intent of this change is to make the olivetti-fringe invisible.
Thanks to Matthias Fuchs for reporting the issue that helped me track
this problem. This was done in issue 46 on the GitHub mirror:
<https://github.com/protesilaos/modus-themes/issues/46>.
Change the default value so that the background is a subtle gray. The
idea is to provide a more usable out-of-the-box experience for those
who are not aware that the themes are customisable.
To restore the old default with the invisible fringes, add this to the
init file before loading the theme:
(setq modus-themes-fringes nil)
As with all user options for themes, changes are applied upon theme
reload.
Change the default value so that the background of the currently
highlighted line with 'hl-line-mode' is a more intense gray than the
previous design. The idea is to provide a more usable out-of-the-box
experience for those who are not aware that the themes are
customisable.
To restore the old default with the more subtle gray, add this to the
init file before loading the theme:
(setq modus-themes-hl-line nil)
As with all user options for themes, changes are applied upon theme
reload.
Change the default value so that the background of the selected line
is a more intense gray than the previous design. The idea is to
provide a more usable out-of-the-box experience for those who are not
aware that the themes are customisable.
To restore the old default with the more subtle gray, add this to the
init file before loading the theme:
(setq modus-themes-completions nil)
As with all user options for themes, changes are applied upon theme
reload.
I plan to introduce some breaking changes (nothing major, but still)
so it is better to express this in the version number. This will be
done in the interest of a better out-of-the-box experience for most
users. I am timing it to coincide with the cut of the emacs-29
branch, which is expected in November.
We cannot use our ordinary entries from each theme's palette as those
are not designed to handle such an edge case. Those faces need to use
the inverse-video attribute which, in turn, affects the combinations
of color we can apply. Our accented backgrounds are designed to
contrast well with our nominal main foreground values, whereas this
case demands colored backgrounds that contrast well with what would
normally be the main background color. Furthermore, this case
requires that colored backgrounds are faithful to their name so that,
say, hi-yellow is yellowish.
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>.
This is for commit 93c291e which is below the ~15 line threshold and
thus does not require copyright assignment to the free software
foundation.
The patch was sent by Paul David as pull request 39 over at the GitHub
mirror: <https://github.com/protesilaos/modus-themes/pull/39>
Quoting from the manual:
The 'solaire-mode' package dims the background of what it considers
ancillary 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 in many cases as it is enabled by default in at
least the very 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.
Because the Modus themes are meant to work everywhere, we cannot
make an exception for Doom Emacs 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 all users. Besides, the
themes are built into Emacs and we must keep their standard high.
As such, 'solaire-mode' is not---and will not be---supported by the
Modus themes. Users who want it must style the faces manually.
Below is some sample code, based on what we cover at length
elsewhere in this manual:
[...]
I periodically test the packages we support to see if they have any
updates we need to cover but also to confirm that they work. 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.
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.
If you think this is a mistake, please let me know: I shall reconsider
this decision.
Even on Debian Sid, they are on version 1.0.2:
<https://packages.debian.org/sid/elpa-modus-themes>.
I don't think anyone should use that and will remove this entry from the
manual if things do not change in the near future.
The user option 'modus-themes-headings' now reads a level 0 heading. It
accepts the same list of properties as all other levels. Currently only
the Org document title is covered, but we may cover more faces if need
be.
Sample:
(setq modus-themes-headings
'((0 . (variable-pitch light (height 1.9)))
(1 . (variable-pitch light (height 1.6) overline))
(2 . (variable-pitch regular (height 1.4) overline))
(3 . (variable-pitch regular (height 1.3) overline))
(4 . (rainbow (height 1.2)))
(5 . (rainbow (height 1.1)))
(t . (variable-pitch extrabold (height 1.05)))))
Read the documentation of 'modus-themes-headings' for the technicalities.
Thanks to Rudolf Adamkovič for proposing the idea on the mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3Cm2y1x5tewl.fsf@me.com%3E>.
Given this change, I am also tweaking the default foreground value of
the org-document-title. It is a bit more saturated, but remains close
to the spirit of the previous one.
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.
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. Furthermore, these faces
colourise too much, making the buffer harder to read.
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>.
It has not been working properly for a long time now. Colours are unset
and are not re-applied when switching between modus-operandi and
modus-vivendi.
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)
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 over at the official mailing
list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87zgkgroi7.fsf%40gmail.com%3E>.
