Before, when modus-themes-deuteranopia was non-nil it would affect diffs
by forcibly applying the default style of modus-themes-diffs with the
sole difference of replacing greens with blues.
Now all these combinations work as intended:
(setq modus-themes-deuteranopia t
modus-themes-diffs 'desaturated) ; nil, 'desaturated, 'bg-only
Thanks to Kevin Le Gouguec for the feedback:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C878rqt4jhm.fsf@gmail.com%3E>.
This reverts commit 3d6221e284. Upon
further inspection, the issue is specific to Emacs 29. I tried to build
the package with Emacs 27, 28, 29, and only the latter produces the
error.
Commit f067d2e explains at length the rationale for wrapping the
reification of the themes in 'eval-and-compile'. While that appears to
solve the problem documented therein, it creates a new one: when we try
to byte compile a theme, we get:
Error: Lisp nesting exceeds ‘max-lisp-eval-depth’
I think byte compilation is nice to have, but it keeps giving us
problems. I am thus disabling it until further notice.
[ Themes shipped with Emacs are not byte compiled (includes
modus-operandi and modus-vivendi). I have seen third-party themes do
the same, such as Bozhidar Batsov's zenburn. ]
Thanks to Omar Antolín Camarena (@oantolin) for reporting the
aforementioned error.
This fixes a problem where not all typographic attributes where applied
to the faces when 'modus-themes-mixed-fonts' was non-nil and the value
of 'modus-themes-markup' included '(bold italic)'.
This makes it possible to customise 'font-lock-comment-face' and have
the changes apply to those faces as well. Such a customisation can, for
example, involve the change of the font family or the addition of a
background colour. We want the whole comment block, including those
special keywords from Git, to look consistent.
This change also makes git-{commit,rebase}-comment-heading attain the
foreground colour of comments, instead of the default one (black or
white). It makes it look part of the comment block.
We now apply the colours directly. The reason is that 'inverse-video'
makes it tricky to override the face as it swaps the foreground with the
background. That behaviour is only needed in special cases: powerline
is not one of them.
Thanks to Thibaut Verron for the feedback in issue 305 over at the
GitLab mirror: <https://gitlab.com/protesilaos/modus-themes/-/issues/305>.
I have tried to limit the wanton use of colour in the relevant buffers
and also align the package with the overall style of the themes.
The currently selected line is affected by the user option
'modus-themes-hl-line'.
Thanks to Ivan Popovych for the feedback over at the official mailing
list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87zgkgroi7.fsf%40gmail.com%3E>.
This is done with the 'highlight-changes-rotate-faces' command when
'highlight-changes-mode' is enabled (the mode is built into Emacs).
Thanks to Philip Kaludercic for the feedback on the mailing list:
https://lists.sr.ht/~protesilaos/modus-themes/<878rs14il4.fsf@posteo.net>
Relevant quote and my explanation:
> it feels to me that the colors used for avy aren't easy to read,
> especially the black foreground on blue background. I'm using
> modus-themes because I have a problem seeing contrast with an overall
> bad vision and I'm usually very happy with the colors you pick: I'm
> wondering why this is different with these colors.
I see what you mean. Here we have a case where the 7:1 ratio is not
consistent with the legibility we perceive. The blue and the black have
a 10:1 contrast, but it still feels inadequate:
(modus-themes-contrast "#77baff" "#000000")
;; => 10.251949912839315
My hypothesis is that this is because of colour perception: blue is the
darkest colour so blue and black feels like "dark and dark".
I have had at least one more case where the modus-themes-intense-blue
felt hard to read while using modus-operandi. I had already reviewed
the blue-intense-bg, but I plan to do so again. Though I also need to
analyse how it is used. For the time being, I feel this problem is
specific to Avy, due to the visuals of its interaction model.
Any small surface area with an intense background that contains a single
character can be harder to read, as the eye may blend everything into a
solid block (especially for black on blue). When the area is larger,
the eye no longer blends the foreground and the background, making
everything appear at its nominal contrast ratio, which in our particular
case is > 10:1 (i.e. very high).
Thanks to Damien Cassou for the feedback:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87czhgt5nm.fsf%40cassou.me%3E>.
The 'modus-themes-version' should be helpful for those who follow the
Git repo and need to report a bug.
The 'modus-themes-report-bug' might help users find the email address of
the mailing list and get started there.
It can lead to situations where there is a mismatch between the latest
change and the recorded time. It also introduces a barrier to entry for
contributors, as they need to set up 'time-stamp.el'.
