I tried to do this with a recent commit but that broke things because
I also included a deftheme declaration. Having that meant that
modus-themes-theme would not declare the theme with all its data,
including its palette.
I looked at loaddefs-generate--emacs-batch and it seems that having
just the theme-autoload line is enough.
This reverts commit 122d53333f.
The reason is that this breaks the package when trying to load a theme
at startup. This was reported by Eamonn Sullivan in issue 69 in the
ef-themes repository: <https://github.com/protesilaos/ef-themes/issues/69>.
I have been facing issues with the macro where certain palette entries
are not known at compile time. I want to experiment with the defun, as
it is always going to be called at runtime.
This reverts commit 80b8de398f.
I wanted to put this in a separate branch for me to test things, but
did it on the main branch and then released it... Reverting as this
causes problems, such as what Morgan Willcock reported in issue 139:
<https://github.com/protesilaos/modus-themes/issues/139>.
The goal is two-fold:
1. Improve the semantics of relevant faces. This now covers the Org
agenda. We want pending/urgent tasks to be rendered in a bold font
and use a vivid colour. Whereas tasks that are not urgent should
have a subtle colour and a normal weight. Thanks to Adam
Porter (GitHub @alphapapa) for discussing this with me in issue
102: <https://github.com/protesilaos/modus-themes/issues/102>.
2. Make the applicable colours be more consistent with the rest of the
theme. In practice, this means that the colour values are cooler
overall and the intensity is lower.
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>.
