This is because the colours they use are not thematically consistent.
I realised this after seeing the Info interface that aikrahguzar
showed me in issue 70: <https://github.com/protesilaos/ef-themes/issues/70>.
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 a4b5f93530.
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>.
It is not needed. I had it there because some colour no longer had the
same mappings after refactoring the themes to be built on top of
Modus. But I am in the process of reviewing those colours now.
I did the changes with keyboard macros as usual. I now notice that
some themes have 26 changes while others have 28. This should probably
be due to some older inconsequential irregularities. I loaded each
theme right now and they all seem okay, so I will let this pass. If
anybody reports a bug, I am always happy to fix it.
At any rate, the main point for this change is to (i) ensure that we
get a complete palette while (ii) that we register the theme's palette
as a "core palette" because these are the correct semantics (e.g. that
ef-light ultimately may have inherited something from modus-operandi
is not relevant to the question "what is your core theme?").
ef-kassio also had a different notice about whether this file is part
of Emacs. I remember reading before that GNU ELPA packages are part of
Emacs, though I prefer to have that notice only if they are part of
emacs.git.
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 on the Modus themes repository (the same principles apply
here): <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.
I am introducing the new 'fg-region' entry in each theme's palette. It
is semantic colour mapping for the region's foreground. By default, it
is set to the special 'unspecified' symbol, meaning that the region's
underlying text colour is not overriden. Setting 'fg-region' to a
colour will override all underlying region foregrounds with that one.
Using palette overrides instead of hardcoded toggles gives users
maximum flexibility over the choice of colour and exact intensity they
need.
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.
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 new semantic colour mappings for
ordinary negative space and its invisible characters:
- bg-space
- fg-space
- bg-space-err
