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.
The change is small, meaning that Kevin does not need to assign
copyright to the Free Software Foundation.
This was done in pull request 166, fixing a regression that I
introduced in commit 08820b2: <https://github.com/protesilaos/modus-themes/pull/166>.
