This is to support new features in Emacs where themes can specify
the set they belong to, as well as whether they are light or dark.
The built-in command is 'theme-choose-variant'.
This is in response to Emacs bug#65468:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65468>. Thanks to
Mauro Aranda for bringing this matter to my attention.
These are used by ansi-term, vterm, and the like. The idea is to
empower users to differentiate background and foreground values. 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.
Thanks to Tony Zorman for reporting the bug that provided the impetus
for this change:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87fs4wforf.fsf%40hyperspace%3E>.
The previous colour was not sufficiently distinct from bg-completion.
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.
The tritanopia themes are not affected by this, as they already use
highly distinct hues.
Thanks to Daniel Mendler[1] 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.
[1] <https://github.com/minad>
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>.
The previous style involved the use of a dim grey background. While
this is good to spot invisible characters quickly, it is bad for users
who want to run 'whitespace-mode' at all times (e.g. for Python 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 negative space and its invisible characters.
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>.
This specifies what the colours are used for. Otherwise they are
confusing.
This change breaks any colour overrides for those names. They need to
be renamed to use "-fringe" instead of "-intense".
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.
These are now used in the rainbow-delimiters package, but there may be
more applications.
Thanks to Aleksei Pirogov for bringing this matter to my attention in
issue 54 on the GitHub mirror: <https://github.com/protesilaos/modus-themes/issues/54>.
