This fixes the faulty macro expansion of nesting the call to
'custom-theme-set-variables' inside 'custom-theme-set-faces'. Actually
you could not catch the error just by using the theme because it
worked as expected...
Also makes the code easier to understand, as it clearly separates faces
from variables (defface VS defvar or defcustom).
There is no need for calls like '(when (>= emacs-major-version 27)'
because unknown faces are simply ignored (e.g. all the faces defined by
the themes whose packages you have not installed).
Also, this have the benefit of greatly simplifying code and its
maintenance.
Basically this defines the 'modus-themes-color' function that lets you
retrieve the colour value assigned to KEY. The key is found in the
association list that contains each theme's colour palette.
Example for how to use this:
(set-face-attribute 'cursor nil :background (modus-themes-color 'blue))
Ongoing discussion in the Modus themes' main repo:
https://gitlab.com/protesilaos/modus-themes/-/issues/119
I have come to the realisation that we are facing a trade-off: either we
allow users to override the colour palette of each theme OR we let the
themes byte compile properly. I am strongly in favour of the latter and
have thus rendered obsolete the relevant customisation option to
override the themes' colours.
Please note that this conclusion is predicated on the knowledge I have
accummulated thus far. I may be wrong and I do not purport to be an
expert. If someone can show me how to both byte compile the themes AND
offer a user-facing variable to override individual colours, then please
let me know---I am happy to follow your guidance.
