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.
This means that the overrides will be the only ones present instead of
the original values. Also, we do not need this in general but only in
the context of the modus-themes-with-colors.
The updated code of the macro relative to commit 16c2c66 works
correectly at all times ONLY WHEN the function that uses
modus-themes-with-colors is added to the modus-themes-after-load-theme-hook
and thus triggered by modus-themes-load-theme.
The enable-theme-functions and load-theme combination is not working
though and I need to figure out why. It leads to excessive lisp nesting.
This makes it easier to place the return value of 'modus-themes-get-theme-palette'
in a 'let*' because something like '(cursor red-warmer)' will come
after '(red-warmer "#ff0000")'.
This might help me sort out the woes with the excessive lisp nesting
of modus-themes-with-colors (see commits 5e77bff and 4514036), but
looks appropriate anyway.
I tried a few variations of that function, but the point is that I
cannot make the macro work inside of a function that is evaluated at
startup in a user's init file. The same function works after I go and
evaluate it manually.
I stumbled across 'define-inline' while looking around in the Emacs
source code, but I am not sure this is what I need... Will need to
test further.
The previous one was faulty because we would get "the first enabled
Modus theme", even if it was not the current one. Whereas I want the
"first enabled only if it is a Modus theme".
