This was done in pull request 212: <https://github.com/protesilaos/modus-themes/pull/212>.
The change is within the ~15-line limit for non-trivial changes,
meaning that Benjamin does not need to assign copyright to the Free
Software Foundation.
This gives users and derivative themes the option to pick a suitable
value for those interfaces.
Thanks to aikrahguzar for making this suggestion in issue 70 of my
ef-themes repository (the ef-themes are built on top of the
modus-themes): <https://github.com/protesilaos/ef-themes/issues/70>.
This is what allows the modus-themes to be loaded in the early-init.el
because they no longer depend on color-name-to-rgb to be available at
that time.
This change was done in pull request 199: <https://github.com/protesilaos/modus-themes/pull/199>.
It is within the ~15-line limit, meaning that Mike does not need to
assign copyright to the Free Software Foundation.
This is because typically themes have a 'provide-theme' in their file,
which we do not have in our theme files. Not doing a 'provide-theme'
at all times can break user configurations.
Thanks to Daniel Colascione for pointing this out in issue 195:
<https://github.com/protesilaos/modus-themes/issues/195>.
We can always refine the implementation details, but at least the
results are looking very promising. I think/hope users will benefit
from this enhancement.
We have to make sure that the value passed to :color is not
'unspecified'. Users may want to do this, given the option they have
via the overrides, and it is a fine use of the system. Internally
though, we have to adjust the :box to do the right thing instead of
throwing an error.
Thanks to JD Smith for reporting a bug along those lines in issue 9 of
my standard-themes repo (they are derived from the modus-themes, hence
the changes here): <https://github.com/protesilaos/standard-themes/issues/9>.
I am generalising the fix for all faces that could exhibit the same
problem. I will check if we need to do the same for some of the underlines.
We want to do this because completion-preview-exact hardcodes a colour
value, which does not work for our purposes.
Thanks to Kevin Fleming for asking me about this in issue 178:
<https://github.com/protesilaos/modus-themes/issues/178>.
This makes it so derivative theme actually get their own colours
instead of those coming from the core theme. Same for user-defined
palette overrides.
Another advantage of this approach is that we keep a separation of
concerns between the different uses we have for the palettes we
retrieve and the structure we want them to have. I prefer this over a
helper function that has to behave according to some optional
parameter.
This is in response to issue 175 by Fritz Gabo, which reports a bug
about derivative themes not getting the right colours when using
modus-themes-with-colors: <https://github.com/protesilaos/modus-themes/issues/175>.
Also thanks to Roshan Shariff for testing my suggested changes (i.e.
this diff) and informing me of getting the expected results out of them.
