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".
This undoes what I was trying to do with commits ef3e0e5 (use 'load'
instead of 'load-themes') and 67b6db3 (let bind hooks to nil).
What I did before was wrong. I was thrown off by the fact that
'enable-theme-functions' works with all themes, not just colour
themes. This includes 'user'. In some tests I also got other
configuration themes like 'use-package' or even the ones that come
from my 'fontaine' and 'spacious-padding' packages. But I did not
bother to figure out when those themes would show up. By default,
at least 'user' is passed to the 'enable-theme-functions'.
With 'emacs -Q':
(defun test (theme)
(message "Current theme is `%s'" theme))
(add-hook 'enable-theme-functions #'test)
(load-theme 'modus-operandi)
;; ;; From the *Messages*:
;;
;; Current theme is ‘user’
;; Current theme is ‘modus-operandi’
This looks cleaner and saves us from the trouble of having to deal
with any hooks after load-theme at this early stage. I took the file
binding from the load-theme source.
Fundamentally, I want to have a theme symbol, like 'modus-operandi'
exist with all the relevant 'theme-properties' so that something like
'modus-themes-list-colors' can work with it even before
modus-operandi-theme.el is loaded.
Normally features get the font-lock-constant-face, but there may be
scenaria where the generic font-lock is not doing the right thing,
whereas the semantic highlighting will. So having this face takes care
of the latter.
Thanks to Eshel Yaron for explaining this to me in the discussion
around Emacs bug 79677: <https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-10/msg01156.html>.
This was the old way of doing things before we had the semantic
palette overrides. Back then it made sense to have a face and then
inherit it, otherwise it was impossible to track was "means" what.
This was the old way of doing things before we had the semantic
palette overrides. Back then it made sense to have a face and then
inherit it, otherwise it was impossible to track was "means" what.
This was the old way of doing things before we had the semantic
palette overrides. Back then it made sense to have a face and then
inherit it, otherwise it was impossible to track was "means" what.
This was the old way of doing things before we had the semantic
palette overrides. Back then it made sense to have a face and then
inherit it, otherwise it was impossible to track was "means" what.
This was the old way of doing things before we had the semantic
palette overrides. Back then it made sense to have a face and then
inherit it, otherwise it was impossible to track was "means" what.
This was the old way of doing things before we had the semantic
palette overrides. Back then it made sense to have a face and then
inherit it, otherwise it was impossible to track was "means" what.
This was the old way of doing things before we had the semantic
palette overrides. Back then it made sense to have a face and then
inherit it, otherwise it was impossible to track was "means" what.
This is related to Emacs bug#79672: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79672>.
What I did was to review ALL the uses of :inherit and try to do the
following:
- Limit recursive inheritence.
- Inherit from Modus faces.
- Do not inherit when semantic palette mappings can be used directly.
There are some exceptions, but the idea is to rely less on :inherit
and more on the palette entries we provide. This is anyway good for
us: I needed to make this change since I introduce the semantic
palette mappings.
In the process of doing this I also reviewed lots of faces. I might
have made some mistakes, but things are looking good overall.
Their original values are fine and we may run into unexpected problems
by limiting them to a subset of supported display specifications (via
the ,c we have there).
We defined the faces just for this case. I think the package should
accept a vector with colour values, like regular rcirc does with the
'rcirc-color-codes'. Then we can check back again.
Yes, the :inverse-video preserves the background but it can make the
foreground unreadable. I think it is better to let hl-line-mode take
priority in this case. Maybe the alternative is to modify the overlay
'priority' property of those highlights, but this is not the theme's
prerogative.
These faces are problematic because their colour coded background is
their essential quality. Having "readable" text here may be well below
the 7:1 contrast target. We have to do this otherwise we will need to
compromise on the background values, which makes them harder to tell
apart and thus less useful for what they are meant to do.
We are trying to fix something that should be handled directly in that
package, namely, for it to just inherit from font-lock instead of
trying to do its own thing.
I have been facing issues with the macro where certain palette entries
are not known at compile time. I want to experiment with the defun, as
it is always going to be called at runtime.
I have had this issue for a while where loading the .elc version of
the themes would result in nil values for the mappings defined in the
modus-themes-common-palette-mappings. I tried a few things and it
seems that this is enough to make things work as expect, i.e. to have
the list reified at compile time so that the individual theme palettes
get all the mappings correctly.
This reverts commit 7111708f15.
I thought this was needed to fix a warning I get about 'nil'
foreground value for a couple of faces. It seems that the mappings in
'modus-themes-common-palette-mappings' are not read and so I suspected
this was because of them not being known at compile time. Apparently,
this does not fix the problem, so I must check elsewhere...
I must have deleted it as part of that botched rebase I did. Anyway,
this sort of thing will not even be visible to users of the marginalia
package, but is still good to have.
This is better for us because then we do not need to have derivative
theme packages necessarily implement their own version of
'modus-themes-to-rotate'. Plus, the user may have forgotten to update
that user option.
We still want to perform a rotation when the current theme is not on
the modus-themes-to-rotate. This is done in response to issue 60 on
the ef-themes repository (but applies to use here too, more so since I
am redesigning the ef-themes to be derived from the modus-themes):
<https://github.com/protesilaos/ef-themes/issues/60>.
It complicates things for us and also has the disadvantage of running
as many times as the setopt variables being set. Users should just
learn to reload their theme and/or Emacs should have some built-in
mechanism. This is not our problem to fix.
Otherwise we end up loading the first among the "known themes" even
when the user had no such intention.
Thanks to Zhengyi Fu for reporting the bug on the Emacs tracker.
I tried many styles, but because the minibuffer colours are
customisable we cannot know if, say, "red background" is going to look
different than what the user has set. The colour inversion is not the
prettiest in this case, but works well.
It uses ':weight bold' whereas we want ':inherit bold'. The latter
gives users the option to modify the font family of the 'bold' face,
such as to make it extrabold.
I do not want to publish a new minor release because I did that
recently and there are not many changes since then. Plus, I would need
to prepare a change log, which I cannot do right now.
Rebuilding the package allows us to include commit bf6c6ce, which
lowers the minimum required version of Emacs to 27.1. Hopefully,
everything will work as intended.
This is in response to bug#78991 by John Sullivan:
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-07/msg00480.html>.
Those were originally contributed by Jimmy Yuen Ho Wong in pull
request 142: <https://github.com/protesilaos/modus-themes/pull/142>.
The changes I making are intended mostly to avoid hardcoding certain
values, so that the palette overrides we provide work as expected.
When calling modus-themes-rotate interactively and with a prefix
argument, reverse the sense of rotation from right to left among the
modus-themes-to-rotate. Explicit calls to modus-themes-rotate can
pass a non-nil REVERSE argument to achieve the same for their THEMES.
* modus-themes.el: (modus-themes-rotate, modus-themes--rotate-p,
modus-themes--rotate, modus-themes--next-in-rotation):
Add an optional REVERSE argument to modus-themes-rotate. When called
interactively this becomes the current prefix argument. Replace
helper functions with a single modus-themes--next-in-rotation. Update
doc strings.
This is in response to the issue 119 by sivaramn: <https://github.com/protesilaos/modus-themes/issues/119>.
In the original Gnus faces, the "ancient" are not the same as "read"
in terms of their colour, though I cannot find what the difference
actually is. It seems to me that "ancient" simply means "read it before".
