This face can be disabled with the following:
(setq bookmark-fontify nil)
Thanks to Mark Barton for reporting the presence of this new face and
for providing valuable feedback in issue 189:
<https://gitlab.com/protesilaos/modus-themes/-/issues/189>.
Expands on commit db21134c9f by Rudolf Adamkovič and follows the
suggestion that was put forward in merge request 33:
<https://gitlab.com/protesilaos/modus-themes/-/merge_requests/33>.
Rudolf's contribution constitutes a minor patch that does not require
copyright assignment to the Free Software Foundation (remember that the
Modus themes are built into Emacs).
The abstraction is done in an effort to ensure consistency between
different face groups, but also to make it easier to propagate
customisation options.
The one option that applies now is for deuteranopia. It means to use a
blue colour instead of a green one to denote a successful state when
this is evaluated:
(setq modus-themes-success-deuteranopia t)
For more on this new variable check commit 70456e93f5.
This means to use a blue colour instead of green to denote a successful
state when (setq modus-themes-success-deuteranopia t).
For details on this new variable refer to commit 70456e93f5.
This only affects (setq modus-themes-diffs 'fg-only-deuteranopia) as it
adds a dim background to the current diff hunk. All other variations of
'modus-themes-diffs' look the same as before.
Note that the meaning of "fg-only" has changed to be red-blue instead of
red-green: <https://gitlab.com/protesilaos/modus-themes/-/issues/183>.
This affects (setq modus-themes-syntax 'yellow-comments) and the other
variants that use yellow comments.
To compare the changes, put these in a buffer and do M-x rainbow-mode
(the package is on GNU ELPA):
;; modus-operandi
(fg-comment-yellow . "#5f4400")
(fg-comment-yellow . "#794319")
;; modus-vivendi
(fg-comment-yellow . "#cab98f")
(fg-comment-yellow . "#d0a070")
The 'pulse-highlight-face' warns in its doc string not to customise it,
though searching through the commit logs in emacs.git as well as greping
the source does not yield any answer as to why that is. The original
commit was in 2009 and it provides no justification whatsoever.
As such, we decide to customise that face regardless: the worst that
could happen is some subtle bug somewhere (i.e. a different default
colour than expected), which we are fully prepared to deal with.
Thanks to Gustavo Barros for reporting this issue and helping search
through the logs to decide on this course of action:
<https://gitlab.com/protesilaos/modus-themes/-/issues/185>.
We now use a more prominent background, which hints at a cyan/teal
colour. The background that was used before was too subtle.
All other options look the same as before.
I think we now are in a position to claim with confidence that the Modus
themes are committed to empower users with red-green colour deficiency.
From now on, every context that has a red/green dichotomy of some sort
and which has no alternative of a red/blue binary should be considered a
serious bug against the themes. I take this issue as seriously as the
primary objective of the themes for a WCAG AAA standard for legibility.
With this new option, as well as everything that has done into
'modus-themes-diffs' (e.g. the earlier commit 133d64e3a9 or the review
of its "fg only" option[1]), we can finally claim that issue 118 is
addressed, at least in principle.[2]
[1]: <https://gitlab.com/protesilaos/modus-themes/-/issues/183>.
[2]: <https://gitlab.com/protesilaos/modus-themes/-/issues/118>.
This makes them conform with either of those:
(setq modus-themes-diffs 'deuteranopia)
(setq modus-themes-diffs 'fg-only-deuteranopia)
Making the themes work well for users with red-green colour deficiency
is a realisable (and laudable) objective that is consistent with our
commitment to uncompromising accessibility.
Given the broad package coverage, this remain work-in-progress that
consists of multiple commits. The original idea was proposed in issue
118 by Hörmetjan Yiltiz:
<https://gitlab.com/protesilaos/modus-themes/-/issues/118>.
Users who could be affected by this will be using old GNU ELPA packages
up to version 0.12.0 (summer 2020) or earlier. Since then we have
updated GNU ELPA to 1.2.0 and 1.3.0, so there is no need for the next
version (1.4.0) to keep this code.
I am pushing this early in the development cycle of 1.4.0 so that we get
plenty of time to deal with any possible breakage.
We are now using blue instead of green for the diary, because the former
is generally better for accessibility and fits in nicely with the
overall aesthetic of the themes.
