I load hl-todo-mode before my humanoid theme and add a new todo
(keyword . face) pair to hl-todo-keyword-faces. I was frustrated for
a while as to why this new pair didn't show up in actual operation.
The answer is that humanoid-themes overwrites
hl-todo-keyword-faces with a hardcoded value.
All this is meant to achieve is to fix the faces in the list to the
relevant colours. This PR offers a more robust solution: for every
word in the actual list hl-todo-keyword-faces when the theme is set,
if that word appears in a canonical alist in the theme code, set the
colour/face to the one in the canonical alist. Otherwise, leave it
alone. This retains edits (additions and deletions) the user makes,
but still fixes the colours.
Original commit message for sole commit:
Instead of hard-coding the value of hl-todo-keyword-faces, alter the
value of any keyword in the list for which we have a value in the
theme's list. This allows users to alter the list before loading the
theme (and retain their own additions) while still using the theme
colours where relevant.
tasmo
commented
2 years ago
I load
hl-todo-modebefore my humanoid theme and add a new todo (keyword . face) pair tohl-todo-keyword-faces. I was frustrated for a while as to why this new pair didn't show up in actual operation. The answer is thathumanoid-themesoverwriteshl-todo-keyword-faceswith a hardcoded value.All this is meant to achieve is to fix the faces in the list to the relevant colours. This PR offers a more robust solution: for every word in the actual list
hl-todo-keyword-faceswhen the theme is set, if that word appears in a canonical alist in the theme code, set the colour/face to the one in the canonical alist. Otherwise, leave it alone. This retains edits (additions and deletions) the user makes, but still fixes the colours.Original commit message for sole commit: