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>.
Those contradict the changes done in commit 4e331d2. In short, we
want a different colour for the hover effects so that it is not
mistaken for other elements.
Thanks to Daniel Mendler[1] for bringing this matter to my attention.
This was done via a private channel and the information is shared with
permission.
[1] <https://github.com/minad>
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.
This allows the user to target the 'theme' completion category in
order to affect the relevant functions. For example, to set
completion styles with 'completion-category-overrides' or define a
custom annotation function with the 'marginalia' package.
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>
The 'success' face is designed to contrast with the 'warning' face
that is used to show overlong summaries. Furthermore, we must not
hardcode the blue colour, as it is not suitable for tritanopia.
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
company/corfu popup, and the Org source blocks (when the user option
'modus-themes-org-blocks' is configured appropriately).
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 intent is to allow other functions that call this one to capture
the return value for their purposes.
Thank to Oliver Epper for the feedback in issue 78 on the GitHub
mirror: <https://github.com/protesilaos/modus-themes/issues/78>.
