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.
I think this is done now. All that remains is to (i) polish the
derived colors because some of them are not nice and (ii) check the
code again to make sure I am not being sloppy.
I wrote those changes earlier, but then forgot to commit. Then I came
back and accidentally reverted/destroyed what I had... This is going
off of memory, but I will need to check again.
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.
This is because both can appear in the same context, whereas I thought
this would never happen.
Thanks to Rudolf Adamkovič for discussing this with me in the context
of the same change for my doric-themes (issue 20):
<https://github.com/protesilaos/doric-themes/issues/20>.
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.
Thanks to Morgan Willcock for discussing with me the use of the
:strike-through style in issue 169: <https://github.com/protesilaos/modus-themes/issues/169>.
The plan is to review all uses of :strike-through to determine which
ones actually benefit from it.
This way the notmuch-tag-deleted is not using a style that is unique
to it. The wavy underline is easy to spot and does not obfuscate the
text of the tag.
Thanks to Morgan Willcock for discussing with me the use of the
:strike-through style in issue 169: <https://github.com/protesilaos/modus-themes/issues/169>.
The plan is to review all uses of :strike-through to determine which
ones actually benefit from it.
This affects how the overrides are handled when they mention a
semantic palette mapping, which itself is a semantic palette mapping.
Thanks to Alexandr Semenov for reporting a relevant bug and testing
this diff in issue 170: <https://github.com/protesilaos/modus-themes/issues/170>.
It is not really a link and it also gets applied to a lot of places
that should not look exactly like links.
Thanks to Morgan Willcock for discussing this with me in issue 140:
<https://github.com/protesilaos/modus-themes/issues/140>.
I added that parameter specifically for this case. When I was
committing edd5b66, I thought I had passed it here, but apparently I
did not because that commit also reverted 5777db8...
For some reason the macro was no longer working with commit 1b66344
after I restarted Emacs. Will investigate further. This should
nevertheless be the final commit that fixes all known issues with
modus-themes-with-colors.
The modus-themes-with-colors should either work on an already loaded
theme or do nothing. Otherwise with the enable-theme-functions we end
up with excessive lisp nesting.
Thanks to Alexandr Semenov for reporting the bug in issue 170:
<https://github.com/protesilaos/modus-themes/issues/170>.
I think I have fixed it. Will continue testing throughout the day. If
it works, then I will bump the version number to trigger a GNU ELPA
rebuild. Will also updated emacs.git.
