Tags

Modus themes version 3.0.0

By Protesilaos Stavrou <info@protesilaos.com> on 2022-10-28

The version that will ship with Emacs 29
========================================

The 'modus-operandi' and 'modus-vivendi' themes (package name is
'modus-themes') have been a part of Emacs since August 2020.  Emacs 28
ships with version 1.6.0 of the themes.  Emacs 29 will include version
3.0.0.

There is no clean upgrade path from the old version of the themes to
the current one.  Users are advised to review their configurations and
consult with the detailed manual of the themes.

I am available to answer any questions, either via my personal email
or on the official sources of the themes.  Find the full list here:
<https://protesilaos.com/emacs>.

Minor breaking changes
======================

I have changed the default value of the following user options:

1. 'modus-themes-hl-line'
2. 'modus-themes-completions'
3. 'modus-themes-fringes'

In the case of the first two, the background of the highlighted line
is made to look a bit more intense.

For the fringes, this tweak makes them visible, using a subtle grey
colour.  By default, "fringe" is an 8-pixel-wide area to the left and
right side of an Emacs window.

The intent of these changes is to make the out-of-the-box experience
consistent with the accessibility considerations of the Modus themes.
Specifically because some users may not realise that the themes are
highly customisable.

To revert to the old defaults, users must include this (or equivalent)
in their init file:

    (setq modus-themes-completions nil
          modus-themes-hl-line nil
          modus-themes-fringes nil)

As always, changes to theme user options take effect upon a reload of
the theme.

This was announced on my website:
<https://protesilaos.com/codelog/2022-10-23-breaking-modus-themes-3-0-0-notice/>.

Support for new faces or changes to existing ones
=================================================

* Refined the 'telega' faces for inline code and preformatted
  elements.  The faces are 'telega-entity-type-code' and
  'telega-entity-type-pre', respectively.  This change makes them
  subject to the style specified in the user option
  'modus-themes-markup'.

  Thanks to Pablo Stafforini for showing me screenshots of how they
  look, as I am not a telega/telegram user and cannot do this myself.
  Done as part of issue 170 on the GitLab mirror:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/170#note_1143975582>.

* Removed all attributes from the 'textsec-suspicious' face.  By
  default, it applies a background, but does not affect the
  foreground.  The result is thus inaccessible in many cases
  (e.g. blue links against a red background).  There is no need for
  such a background though, as the warnings are accompanied by the
  relevant emoji: ⚠️.

  To support this face, we need it to affect the foreground as well.

* Deleted some 'consult' "preview" faces in the interest of
  consistency.  This is to match the current style of the project:
  <https://github.com/minad/consult/commit/1343e39fefcf8a28a7a415aa4b0a8ff7094370bf>.

* Expanded support of the built-in 'diff-mode' faces to include the
  'diff-changed-unspecified'.  It is made to look the same as
  'diff-changed', i.e. yellow-tinted.  There is a good chance that a
  user will never see this face in action (I only encountered it
  once).

* Reworked all the 'highlight-regexp' faces (like 'hi-yellow') to use
  bespoke colour values.

  These faces need to have a background that is consistent with their
  semantics.  Furthermore, they need to use the 'inverse-video'
  attribute which, in turn, affects the combinations of colour we can
  apply.  Our accented backgrounds are designed to contrast well with
  our nominal main foreground values, whereas this case demands
  coloured backgrounds that contrast nicely with what would normally
  be the main background colour.  As such, we cannot apply our
  ordinary entries from each theme's palette.  It would be inefficient
  to expand the palette of each theme just for this edge case.

  Thanks to Kevin Kainan Li for the feedback on the mailing list, where
  they informed me that the previous design was too dark/mute (and I
  agreed with that assessment) and provided feedback on my samples:
  <https://lists.sr.ht/~protesilaos/modus-themes/%3CCAMTq2Vp3Nnzv-i9wJdq4-OJ4X_QfWXySpUtAieBy0dgKLEOSBg%40mail.gmail.com%3E>.

* Recoloured the 'modus-themes-completion-match-1' to use a shade of
  blue instead of cyan.  This contributes to the distinctiveness of
  those matches relative to 'modus-themes-completion-match-0' and the
  other groups.  These faces are used in completion User Interfaces,
  such as 'vertico', 'corfu', 'orderless'.  They are subject to the
  user option 'modus-themes-completions'.

* Added support for the 'olivetti-fringe' face.  Its background is the
  same as the main background, meaning that the fringes are invisible
  when 'olivetti-mode' is enabled.  Thanks to Matthias Fuchs for
  producing a report that helped me track this problem.  It was done
  in issue 46 on the GitHub mirror:
  <https://github.com/protesilaos/modus-themes/issues/46>.

Miscellaneous
=============

* Added the new Emacs 29 theme properties to 'modus-operandi' and
  'modus-vivendi'.  These make the themes work with the new built-in
  command 'toggle-theme'.  Thanks to Philip Kaludercic for the patch
  and for the work on this in emacs.git:
  <https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg00886.html>.

* Refrained from deprecating the 'modus-themes-toggle' command in
  favour of the new generic 'toggle-theme'.

  The 'toggle-theme' is not functionally equivalent to the command
  'modus-themes-toggle' due to the optional arguments it accepts.
  With 'toggle-theme' we are prompted to confirm loading the theme,
  due to how unsafe themes can be...  Further, we are asked to add the
  loaded theme to the list of "safe" themes.  This only applies to the
  packaged version of the 'modus-themes', not the items that are built
  into Emacs.

  These prompts are consistent with how 'load-theme' works, but not
  with what the user of 'modus-themes-toggle' has come to expect.

  Users who do not like to maintain a 'custom-file' (like me) are thus
  penalised each time they invoke the command.

  The 'modus-themes-toggle' will only be deprecated if there is, say,
  a user option in Emacs that disables those prompts each time a theme
  is loaded.  Basically, we need an arrangement that just toggles
  themes without questions.

  Thanks to Rudolf Adamkovič for suggesting the idea and to Philip
  Kaludercic for the 'toggle-theme' (and related functionality):
  <https://lists.sr.ht/~protesilaos/modus-themes/%3C877d116lh4.fsf%40posteo.net%3E#%3Cm2lepgrd8l.fsf@me.com%3E>.

* Corrected the one-line description of the 'modus-vivendi' theme,
  which was describing itself as a "light" theme.

* Ensured that the manual and all doc strings in the code use American
  English, per the convention of emacs.git (my CHANGELOG still uses
  what I prefer).  Thanks to Stefan Kangas for contributing to this
  effort with a patch that properly renders 'non-nil' in the texinfo
  output as 'non-@code{nil}'.

* Made other minor tweaks and refinements.

Modus themes version 2.7.0

By Protesilaos Stavrou <info@protesilaos.com> on 2022-10-01

Support for packages or faces
=============================

* Reinstated support for 'centaur-tabs'.  I had removed it in commit
  2235ce5 (done on 2022-08-02) for version 2.5.0 of the modus-themes.
  At the time I wrote:

      centaur-tabs has a bug where it cannot read the value of a face if it
      uses the standard ':inherit' attribute.  I have sent a patch to fix it,
      but have received no response since February:
      <https://github.com/ema2159/centaur-tabs/pull/179>.

      Relevant reports:

      - <https://github.com/protesilaos/modus-themes/issues/30>
      - <https://gitlab.com/protesilaos/modus-themes/-/issues/288>
      - <https://github.com/protesilaos/modus-themes/issues/15>

      I am happy to reinstate support for centaur-tabs as soon as the package
      gets the maintenance it needs.

  My patch/pull-request is now merged and the package is actively
  maintained once again.  Hence the decision to bring back support for
  it, as promised.

* Applied styles for the 'icon-button' face of Emacs 29.

* Styled the 'log-edit-headers-separator' face of Emacs 29 (it was
  introduced upstream by a patch of mine).

* Made the 'gnus-summary-low-unread' face inherit from the 'italic'
  face like the rest of that subgroup of faces.  This helps
  differentiate it from the 'gnus-summary-high-unread' face.  Thanks
  to Mark Simpson for pointing out the possibility of conflating those
  two faces: <https://lists.sr.ht/~protesilaos/modus-themes/%3Cm2r0zszc2z.fsf@gmail.com%3E>.

* Covered the 'read-multiple-choice-face' by adding a noticeable
  background colour to it.  The default attributes it has, which look
  like other key bindings (bold and blue) plus an underline are
  technically okay, though the context of this face is in the echo
  area which is one line tall.  Moreover, the highlighted keys are
  inlined with other text.  These make it difficult to spot the
  highlights without some extra spacing.  I use the addition of a
  background in Org's export dispatcher interface which also has some
  unique requirements (the 'org-dispatcher-highlight' face).  The
  principle is to have theme-wide consistency (e.g. "all key bindings
  must look the same") EXCEPT when the specifics require a different
  set of styles in the interest of usability.

* Extended the coverage of the 'auctex' package's faces to include the
  'font-latex-underline-face'.  Thanks to Luis Miguel Castañeda for
  reporting a typo I made which caused an error:
  <https://lists.sr.ht/~protesilaos/modus-themes/%3C7h7d2oudpb.fsf@imaginarymagnitude.net%3E>

* Added support for 'crontab-mode'.  Thanks to Antonio Ruiz for the
  patch: <https://lists.sr.ht/~protesilaos/modus-themes/patches/35080>.  It
  is below the ~15 line threshold and thus requires no copyright
  assignment to the Free Software Foundation.

* Extended support for the 'company' package's 'company-scrollbar-bg'
  and 'company-scrollbar-fg' faces.

* Added support for the 'spell-fu' package.  Thanks to Antonio Ruiz
  for the patch: <https://lists.sr.ht/~protesilaos/modus-themes/%3C87fshnq7uv.fsf%40purelymail.com%3E>.
  Same as further above for Antonio's copyright status.

* Moved the 'selectrum-prescient' faces to the 'prescient' group, to
  be consistent with changes in the respective upstream packages.
  Thanks to okamsn for the contribution, which was done in pull
  request 41 on the GitHub mirror: <https://github.com/protesilaos/modus-themes/pull/41>.
  The user okamsn has assigned copyright assignment to the Free
  Software Foundation, although this patch is within the allowed
  limits.

Change to 'fill-column-indicator'
=================================

Made the 'fill-column-indicator' face more noticeable.  It is what the
'display-fill-column-indicator-mode' uses to draw a line on where the
'fill-column' is.

This change is in response to private messages I received as well as
this, at parts impolite and toxic, thread that I refrained from
participating in:
<https://lists.gnu.org/archive/html/help-gnu-emacs/2022-08/msg00255.html>.

[ I do not follow that mailing list, by the way.  All my projects have
  multiple communication channels and I always reply in a timely
  fashion.  Social media, fora about Emacs, generic mailing lists,
  etc. are not among those channels.
  <https://protesilaos.com/codelog/2022-07-24-report-issues-official-channels/>. ]

The core idea is that the previous design was (1) considered
"invisible" and (2) it prevented the customisation of the user option
'display-fill-column-indicator-character'.

I am addressing point 1, but point 2 puts us in an awkward spot as we
would then not be allowed to use a background and a height value.  Not
doing so produces a dashed line by default, with the dashes further
apart the greater the line-spacing is (especially in, say, Org
headings that can have a greater height than paragraph text).  It
looks broken and I keep getting requests to fix what is not the
themes' fault.  So no, the themes will remain opinionated in this
regard by ignoring 'display-fill-column-indicator-character' through
the styling they apply to make the line contiguous.

For context, also read Emacs bug#57424 and please don't take my words
in a private message out of context.  If I need to state my opinion in
a public setting, I know how to do it.
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57424>.

Refinement to modus-vivendi 'bg-diff-focus-removed' colour
==========================================================

Made the default removed diff background slightly more luminant.  The
colour is seen in diff-mode, ediff, and the Magit focused diff hunk.

When the user option 'modus-themes-diffs' is set to either 'bg-only' or
'desaturated', this colour is used to highlight word-wise ("refined")
changes.  The increased luminance lets it stand out more compared to the
more subtle backdrop.

Thanks to Kévin Le Gouguec for bringing this issue to my attention and
for discussing it with me:
<https://lists.sr.ht/~protesilaos/modus-themes/%3C87bks4i9tg.fsf@gmail.com%3E>

Note about 'goto-address-mode'
==============================

Quote from the manual:

    The built-in 'goto-address-mode' uses heuristics to identify URLs and
    email addresses in the current buffer.  It then applies a face to them
    to change their style.  Some packages, such as 'notmuch', use this
    minor-mode automatically.

    The faces are not declared with 'defface', meaning that it is better
    that the theme does not modify them.  The user is thus encouraged to
    consider including (or equivalent) this in their setup:

        (setq goto-address-url-face 'link
              goto-address-url-mouse-face 'highlight
              goto-address-mail-face 'link
              goto-address-mail-mouse-face 'highlight)

    My personal preference is to set 'goto-address-mail-face' to nil, as
    it otherwise adds too much visual noise to the buffer (email addresses
    stand out more, due to the use of the uncommon '@' character but also
    because they are often enclosed in angled brackets).

Changes to the manual
=====================

* Fixed a few typos and ensured that spelling using American English
  as that is what emacs.git requires.

* Added the missing ':config' keywords from the example configuration
  of the 'circadian' package.  Thanks to Koen van Greevenbroek for the
  patch: <https://lists.sr.ht/~protesilaos/modus-themes/%3C8735cb6zm3.fsf%40posteo.net%3E>.

Modus themes version 2.6.0

By Protesilaos Stavrou <info@protesilaos.com> on 2022-08-19

Changes to supported faces or face groups
=========================================

* Made the 'font-lock-warning-face' adapt to comments.  This changes the
  face from a yellow to a red hue when the user adds a value to
  'modus-themes-syntax' which includes 'yellow-comments' property.
  Before, this face was indistinguishable from yellow comments due to a
  regression in version 2.5.0 of the themes.  Thanks to Augusto Stoffel
  and Manuel Uberti for their feedback on the mailing list:
  <https://lists.sr.ht/~protesilaos/modus-themes/%3C87r11k1c22.fsf%40gmail.com%3E>.

* Applied a consistent foreground color (a not-so-intense yellow hue) to
  the 'org-checkbox' and 'markdown-gfm-checkbox-face'.  The change comes
  from the discussion on the mailing list where it became apparent that
  a bit of colour is needed for such constructs:
  <https://lists.sr.ht/~protesilaos/modus-themes/%3Cm2fsi9cja4.fsf%40me.com%3E>.

  Thanks to Rudolf Adamkovič, Christian Tietze, and Karthik Chikmagalur
  for their participation.

* Added support for the 'mu4e-related-face'.  Thanks to Simon Pugnet for
  the feedback on the mailing list:
  <https://lists.sr.ht/~protesilaos/modus-themes/%3C87edxhvqwp.fsf@polaris64.net%3E>.

* Included support for the 'consult-preview-insertion' face.  There are
  two reasons for adding this:

  1. It decouples it from the 'region' face, which means that the user
     option 'modus-themes-region' no longer has an unintended effect on
     it.

  2. It makes it look consistent with the 'rectangle-preview' face (see
     it in action with C-x SPC, move point down a few lines, type C-t
     and then insert some text).  I feel these sort of previews need to
     look the same, though I don't have a strong attachment to the style
     now in use.

Removed support for the 'solaire' package
=========================================

The 'solaire-mode' package dims the background of what it considers
ancillary "UI" buffers, such as the minibuffer and Dired buffers.  The
Modus themes used to support Solaire on the premise that the user was
(i) opting in to it, (ii) understood why certain buffers were more gray,
and (iii) knew what other adjustments had to be made to prevent broken
visuals (e.g. the default style of the 'modus-themes-completions' uses a
subtle gray background for the selection, which with Solaire becomes
practically invisible).

However, the assumption that users opt in to this feature does not
always hold true.  There are cases where it is enabled by default such
as in the popular Doom Emacs configuration.  Thus, the unsuspecting user
who loads 'modus-operandi' or 'modus-vivendi' without the requisite
customizations is getting a sub-par experience; an experience that we
did not intend and cannot genuinely fix.

[ Relevant reading about "The case of git-gutter, the modus-themes, and
  Doom Emacs":
  <https://protesilaos.com/codelog/2022-08-04-doom-git-gutter-modus-themes/> ]

Because the Modus themes are meant to work everywhere, we cannot make an
exception for Doom Emacs and/or Solaire users.  Furthermore, we shall
not introduce hacks, such as by adding a check in all relevant faces to
be adjusted based on Solaire or whatever other package.  Hacks of this
sort are unsustainable and penalize the entire userbase.  Besides, the
themes are built into Emacs and we must keep their standard high.

The fundamental constraint with Solaire is that Emacs does not have a
real distinction between "content" and "UI" buffers.  For themes to work
with Solaire, they need to be designed around that package.  Such is an
arrangement that compromises on our accessibility standards and/or
hinders our efforts to provide the best possible experience while using
the Modus themes.

As such, 'solaire-mode' is not---and will not be---supported by the
Modus themes (or any other of my themes, for that matter).  Users who
want it must style the faces manually.  Below is some sample code, based
on what we cover at length in the manual:

    (defun my-modus-themes-custom-faces ()
      (modus-themes-with-colors
        (custom-set-faces
         `(solaire-default-face ((,class :inherit default :background ,bg-alt :foreground ,fg-dim)))
         `(solaire-line-number-face ((,class :inherit solaire-default-face :foreground ,fg-unfocused)))
         `(solaire-hl-line-face ((,class :background ,bg-active)))
         `(solaire-org-hide-face ((,class :background ,bg-alt :foreground ,bg-alt))))))

    (add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-custom-faces)

Changes to the manual
=====================

* Added a missing parenthesis to a sample code block.  Thanks to Paul
  David for the contribution in pull request 39 on the GitHub mirror:
  <https://github.com/protesilaos/modus-themes/pull/39>.

* Clarified the wording of individual statements pertaining to the need
  of reloading a theme for changes to user options to become effective.

Modus themes version 2.5.0

By Protesilaos Stavrou <info@protesilaos.com> on 2022-08-03

This entry documents the changes made to the project since the
publication of version 2.4.0 on 2022-06-01.  It spans more than 60
commits to an already stable project.

The 'modus-operandi' and 'modus-vivendi' themes are built into Emacs-28
(latest stable release) or later, and are available on GNU ELPA as well
as other archives.  Emacs-28 ships version 1.6.0, while the current
'master' branch (i.e. Emacs-29) and, by extension, GNU ELPA include the
latest tagged release.  The packaged version is available as
'modus-themes'.

Read the manual inside Emacs by evaluating:

    (info "(modus-themes) Top")

Or visit: <https://protesilaos.com/emacs/modus-themes> (the website only
documents the latest version).

Enhancement to the user option 'modus-themes-headings'
======================================================

The user option 'modus-themes-headings' now reads a level 0 heading in
addition to numbers 1--8.  Heading 0 accepts the same list of properties
as all other levels (please consult the doc string of the user option or
the corresponding entry in the manual).  Currently only the value of the
Org #+title is affected (face is 'org-document-title'), but we may cover
more faces if needed.

Sample configuration:

    ;; The `modus-themes-headings' is an alist with lots of possible
    ;; combinations, including per-heading-level tweaks: read the
    ;; manual or its doc string.
    (setq modus-themes-headings
          '((0 . (variable-pitch light (height 2.2)))
            (1 . (rainbow variable-pitch light (height 1.6)))
            (2 . (rainbow variable-pitch light (height 1.4)))
            (3 . (rainbow variable-pitch regular (height 1.3)))
            (4 . (rainbow regular (height 1.2)))
            (5 . (rainbow (height 1.1)))
            (t . (variable-pitch extrabold)))

Given this change, I am also tweaking the default foreground value of
the 'org-document-title'.  It is a bit more saturated than before, but
remains close to the spirit of the previous one.

Thanks to Rudolf Adamkovič for proposing the idea on the mailing list:
<https://lists.sr.ht/~protesilaos/modus-themes/%3Cm2y1x5tewl.fsf@me.com%3E>.

Stylistic tweak to the user option 'modus-themes-syntax'
========================================================

Prevented the 'alt-syntax' property from desaturating the effect of the
'yellow-comments' property when the two would be combined.  Such as:

    (setq modus-themes-syntax '(alt-syntax yellow-comments))

The previous design was incorrect because it was always using the faint
variant of the yellow comments, as if the user had specified:

    (setq modus-themes-syntax '(alt-syntax faint yellow-comments))

[ Read the doc string of 'modus-themes-syntax' or the manual for an
  explanation of all properties and their combinations. ]

Review of the Isearch (and related) colours
===========================================

Emacs' standard search has a face for the currently matched query and
all its inactive matches.  The faces are 'isearch' and 'lazy-highlight',
respectively.  Before, we were using a green background by default for
the 'isearch' face and a cyan background for the 'lazy-highlight'.  This
was a choice that was made in the early days of the project when the
palette was not yet fully realised.

Green and cyan do not always contrast well side-by-side (subject to
hardware capabilities and environmental lighting), so the 'isearch' face
also had an added bold weight.  This was not my preference, but it was
necessary under the circumstances.  The previous combinations were also
not ideal when the user option 'modus-themes-deuteranopia' was set to a
non-nil value: the blue background which was used instead of the green
one could be conflated with the subtle teal of the 'lazy-highlight'
under certain circumstances, such as poor colour reproduction at the
monitor level or in terminal emulators with limited colour support.

The new colours (intense yellow for active matches and subtle cyan for
lazy ones) are complementary, meaning that they are naturally easy to
tell apart.

[ Read "Colour theory and techniques used in the Modus themes":
  <https://protesilaos.com/codelog/2022-04-21-modus-themes-colour-theory/> ]

These specific hues are also well-suited for users with red-green colour
deficiency: yellow stays as-is, while the cyan colour becomes a bit more
grey though remains distinct.  As such, we do not need to run the helper
function 'modus-themes--deuteran' to set the style based on the value of
'modus-themes-deuteranopia'.

The new colours do not clash with the style of the relevant 'match' face
(used by 'M-x occur', 'M-x grep', and related), nor with the various
permutations of the 'region' face (subject to the user option
'modus-themes-region').

Finally, the bold weight has been removed from the 'isearch' face.  It
was always a kludge.  Also, it would make paragraphs rendered in the
'variable-pitch' face (or proportional fonts in general) jump around as
the user would move between the matches, because bold letters occupy
more space than their regular weight counterparts so they affect the
length of the line.  This problem was reported by Augusto Stoffel on the
mailing list: <https://lists.sr.ht/~protesilaos/modus-themes/%3C87sfnbswe9.fsf@gmail.com%3E>.

Rewrote parts of the colour preview commands
============================================

The 'modus-themes-list-colors', 'modus-themes-list-colors-current' are
commands that produce a buffer which shows previews of every entry in
the palette.  Their code has been simplified and they now produce a
warning when the display terminal has limited colour support.
Furthermore, they read any overrides as specified in the user options
'modus-themes-operandi-color-overrides', 'modus-themes-vivendi-color-overrides'.

The "summertime" re-spin of colour overrides
============================================

The manual now includes a complete hand-crafted example of a pair of
themes that override the default palette.  This is done as a technology
demonstration.  It is not considered an "official" extension of the
Modus themes and will never be part of the code base as it does not
conform with our lofty accessibility standards.  However, I took great
care in picking the colour overrides in the hope that users will (i)
have a usable theme, should they opt for it, and (ii) they recognise the
potential of our colour-overriding feature.

Screenshots and related information:
<https://protesilaos.com/codelog/2022-07-26-modus-themes-color-override-demo/>.

Thanks to user “Summer Emacs” for (i) suggesting the name “summertime”,
(ii) testing variants of this in her setup, and (iii) sending me
feedback on possible tweaks and refinements. All errors are my own.

The idea for this project came from an exchange where Summer discovered
an old theme of mine (from my pre-Emacs days) and asked if I had
anything like it for Emacs.  Voilà!

[ This information is shared with permission. ]

As for whether I have more plans... "Perhaps!" ;)

Removed support for certain packages or face groups
===================================================

I periodically install and use the packages we support to see if they
have any updates we need to cover but also to confirm that they work.
Usually, the user does not learn about this work, as I don't need to
make any changes or will make some minor tweaks.  When I think that the
package is not in a good shape, I remove it from the list of explicitly
supported packages, meaning that the modus-themes no longer cover the
faces it defines.  The removal of any package is done on a case-by-case
basis.  If you disagree with this decision, please inform me about and I
shall reconsider.

* centaur-tabs :: Those of you who have been reading these release notes
  are aware of a bug in centaur-tabs which basically prevents us from
  using the standard ':inherit' attribute to style the centaur-tabs
  faces.  I have sent a patch to fix it, but have received no response
  since February: <https://github.com/ema2159/centaur-tabs/pull/179>.
  To me, this gives the package the "unmaintained" status, though I am
  happy to revert the change as soon as it gets the maintenance it
  needs.

  Relevant reports (and I got many others in my private inbox):

  - <https://github.com/protesilaos/modus-themes/issues/30>
  - <https://gitlab.com/protesilaos/modus-themes/-/issues/288>
  - <https://github.com/protesilaos/modus-themes/issues/15>

* cursor-flash :: its default face should be visible enough.

* dynamic-ruler :: The package does not build on my Emacs 29.  Also, its
  default faces are usable even without our recolouring.

* emacs-dashboard :: Its default faces inherit from basic faces that we
  already support.

* frog-menu :: I have not seen this package being used anywhere.  I
  suspect it is because it has not found a niche between transient,
  hydra, and embark.

* mct :: A few months ago I announced that its development is
  discontinued.  Either use vertico or switch to what Emacs provides as
  a built-in option: <https://protesilaos.com/codelog/2022-04-14-emacs-discontinue-mct/>.

* org-treescope :: The package points to a GitHub repo, which is
  archived.  The current source is on GitLab, but the package is not
  updated accordingly.  This makes me believe it is not actively
  maintained and am thus removing it from the list.

* paradox :: When I tried paradox, it took over my C-c g binding which I
  have for Magit.  As an Emacs user, I consider this an unacceptable
  transgression.  Looking at paradox's git repo, the project is not
  maintained.  If things change, I am happy to reinstate support for it.

* vc-annotate (built-in) :: It has not been working properly for a long
  time now.  Colours are unset and are not re-applied when switching
  between the 'modus-operandi' and 'modus-vivendi' themes.

  Furthermore, the way 'vc-annotate-color-map' intersects with
  'vc-annotate-background-mode' puts us in an awkward spot: when the
  mode is non-nil, the mapped values are used as backgrounds WITHOUT
  giving us the chance to make the appropriate adjustments to the
  foreground (so we end up with inaccessible colour combinations).  This
  means that we must fix a problem which is not ours by overriding the
  user option of the background altogether.  A theme outright disabling
  user options is bad form.

  Even documenting a user-level set of configurations will not suffice,
  as the results are unreliable.  I tried the code which I copy further
  below to test annotation with/without background, plus the change in
  values when switching between modus-operandi and modus-vivendi.
  Again, colours are not updated properly (I know the buffer of 'M-x
  vc-annotate' needs to be generated again), as 'modus-operandi' may
  retain the values set by 'modus-vivendi' or vice-versa.

  Ultimately, I feel 'vc-annotate' needs to be refactored to use
  ordinary faces in ordinary ways.  Or, at least, not try to outsmart
  the user/theme about the choice of colours.

  Thanks to Philip Kaludercic for starting the thread about the
  'vc-annotate-background-mode' which reminded me about this problem:
  <https://lists.sr.ht/~protesilaos/modus-themes/%3C875ylfxkgi.fsf@posteo.net%3E>.

  The code I alluded to:

      (setq vc-annotate-background-mode nil)

      (defun my-modus-themes-vc-annotate ()
        ;; Actual values are for demo purposes
        (modus-themes-with-colors
          (if vc-annotate-background-mode
              (setq vc-annotate-background bg-alt
                    vc-annotate-color-map
                    `((20 .  ,red-intense-bg)
                      (40 .  ,red-subtle-bg)
                      (60 .  ,red-refine-bg)
                      (80 .  ,yellow-intense-bg)
                      (100 . ,yellow-subtle-bg)
                      (120 . ,yellow-refine-bg)
                      (140 . ,magenta-intense-bg)
                      (160 . ,magenta-subtle-bg)
                      (180 . ,magenta-refine-bg)
                      (200 . ,cyan-intense-bg)
                      (220 . ,cyan-subtle-bg)
                      (240 . ,cyan-refine-bg)
                      (260 . ,green-intense-bg)
                      (280 . ,green-subtle-bg)
                      (300 . ,green-refine-bg)
                      (320 . ,blue-intense-bg)
                      (340 . ,blue-subtle-bg)
                      (360 . ,blue-refine-bg)))
            (setq vc-annotate-background nil
                  vc-annotate-color-map
                  `((20 . ,red)
                    (40 . ,magenta)
                    (60 . ,magenta-alt)
                    (80 . ,red-alt)
                    (100 . ,yellow)
                    (120 . ,yellow-alt)
                    (140 . ,fg-special-warm)
                    (160 . ,fg-special-mild)
                    (180 . ,green)
                    (200 . ,green-alt)
                    (220 . ,cyan-alt-other)
                    (240 . ,cyan-alt)
                    (260 . ,cyan)
                    (280 . ,fg-special-cold)
                    (300 . ,blue)
                    (320 . ,blue-alt)
                    (340 . ,blue-alt-other)
                    (360 . ,magenta-alt-other))))))

      (add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-vc-annotate)

Revised supported faces or face groups
======================================

* Enhanced the default background colour of the current date in the Org
  agenda.  This is a subtle change, all things considered, which makes
  it easier to discern where the highlight is while it remains close to
  the spirit of the previous design.  The idea is to not add too much
  saturation here, because the buffer is already "busy" with lots of
  highlights.  Thanks to Daniel Mendler for the feedback on the mailing
  list: <https://lists.sr.ht/~protesilaos/modus-themes/%3C3d8b1096-a7db-1e08-fefe-d39bed4a7ea3@daniel-mendler.de%3E>.

* Restyled the 'M-x man' and 'M-x woman' faces to have a bit more
  saturation.  A while ago I desaturated the 'Man-overstrike' and
  'woman-bold' faces on the premise that the added bold weight would be
  sufficient.  However, the bold weight may sometimes not draw the
  desired attention, such as at small point sizes or with certain font
  configurations.  As such, the added intensity in colour is necessary.

* Changed the Selectrum quick key faces ('selectrum-quick-keys-match'
  and 'selectrum-quick-keys-highlight') to have the same style as Avy,
  Vertico's own "quick keys", and related.  For a technical analysis,
  read "Modus themes: case study on Avy faces and colour combinations":
  <https://protesilaos.com/codelog/2022-04-20-modus-themes-case-study-avy/>.

* Made internal adjustments so that 'M-x list-packages' inherits from
  the standard 'success', 'warning', and 'error' faces instead of adding
  its own face attributes.  In practice, the user will notice a change
  for new packages in the listing if 'modus-themes-deuteranopia' is
  non-nil.

* Introduced the same inheritance rules as above for the 'syslog'
  package (mutatis mutandis).

* Increased the saturation of the 'package-status-available' face, which
  is shown in the 'M-x list-packages' buffer.  The overall effect is
  subtle, though sufficiently noticeable.

* Revised the faces of the 'deft' package to make it look consistent
  with the rest of the theme's relevant interfaces (to the extent
  possible as Deft uses a non-standard presentation).

* Aligned the 'speedbar-highlight-face' with the user option
  'modus-themes-intense-mouseovers'.

* Refined the 'highlight-thing' face (see package of the same name).
  This makes it stand out more and it also aligns it with the standard
  'match' face, which is pertinent here.

* Amplified the saturation of the 'dired-git-info' face.  Makes it
  easier to differentiate the Git commit text from the Dired listing,
  without drawing too much attention to itself.

* Adjusted the hue of the 'easy-jekyll-help-face' from teal to blue.
  This makes it look more like the standard 'help-key-binding' face,
  although 'easy-jekyll' does not align with upstream Emacs in this
  regard.

* Intensified the background of 'rectangle-preview' to work even in
  cases where a grey background is already on display.  This face is
  used for the 'string-rectangle' command (e.g. C-x SPC to draw a
  rectangle and C-t to insert text in its stead---works as a simple
  "multiple cursors" on a straight line).

Support for new faces or face groups
====================================

* chart (built-in)
* denote
* edmacro-label (Emacs 29)
* info+
* leerzeichen

A comment on 'info+'.  As is the case with PACKAGE+ packages from the
Emacs Wiki, info+ defines lots of faces that hardcode colour values
instead of inheriting from basic faces.  It does so for no good reason
and the results will likely not look decent in any theme.  Furthermore,
these faces colourise too much even when the colour values can be
appropriately combined (ceteris paribus), making the buffer harder to
read.

The support I add for info+ is consistent with the design principles of
the modus-themes, one of which is to avoid exaggerations as those
indirectly affect legibility.  As such, some of the changes I introduce
here outright remove colouration, while others align the various
constructs with the overall aesthetic of the themes.

Note that, by default, info+ adds clickable buttons to glossary terms.
This produces awkward combinations such as by buttonising the "string"
component inside of what actually is a function's argument.  So you
have, say, FORMAT-[STRING] where "[]" represents the button: the FORMAT
gets one face and the [STRING] another, even though they are part of a
single argument.  To me this looks broken and is counter-productive,
though it is not up to the theme to decide how packages fontify the
various constructs.  At any rate, button styles at the theme level are
controlled by the user option 'modus-themes-box-buttons'.

Thanks to Jonas Collberg for the feedback in issue 33 over at the GitHub
mirror: <https://github.com/protesilaos/modus-themes/issues/33>.

Miscellaneous
=============

* Named the mailing list address as the =Maintainer:= of Denote.
  Together with the other package headers, they help the user find our
  primary sources and/or communication channels.  This change conforms
  with work being done upstream in package.el by Philip Kaludercic.  I
  was informed about it here:
  <https://lists.sr.ht/~protesilaos/general-issues/%3C875ykl84yi.fsf%40posteo.net%3E>.

* Addressed byte compilation warnings in doc strings pertaining to the
  use of literal quotes.  Thanks to Matt Armstrong and Rudolf Adamkovič
  for the feedback on the mailing list:
  <https://lists.sr.ht/~protesilaos/modus-themes/%3C87bktlvgyy.fsf@rfc20.org%3E>.

* Fixed the ':link' value in the declaration of the user options
  'modus-themes-operandi-color-overrides', 'modus-themes-vivendi-color-overrides'.
  It once again directs to the correct heading in the manual.

* Documented all the aforementioned, where necessary.

* Mentioned my 'fontaine' and 'lin' packages in the relevant sections of
  the manual.  The former helps set fonts and switch between font
  presents.  The latter is a stylistic variant of hl-line (its
  documentation explains its raison d'être).

Modus themes version 2.4.0

By Protesilaos Stavrou <info@protesilaos.com> on 2022-06-01

This entry documents the changes made to the project since the
publication of version 2.3.0 on 2022-04-01.  It spans more than 60
commits to an already stable project.

The 'modus-operandi' and 'modus-vivendi' themes are built into Emacs-28
(next stable release) or later, and are available on GNU ELPA as well as
other archives.  Emacs-28 ships version 1.6.0, while the current
'master' branch (i.e. Emacs-29) and, by extension, GNU ELPA include the
latest tagged release.  The packaged version is available as
'modus-themes'.

Read the manual inside Emacs by evaluating:

    (info "(modus-themes) Top")

Or visit: <https://protesilaos.com/emacs/modus-themes>.

Migration to SourceHut
======================

The sources of the project are as follows:

- Git repo on SourceHut: <https://git.sr.ht/~protesilaos/modus-themes>
  - Mirrors:
    - GitHub: <https://github.com/protesilaos/modus-themes>
    - GitLab: <https://gitlab.com/protesilaos/modus-themes>
- Mailing list: <https://lists.sr.ht/~protesilaos/modus-themes>

- Official manual: <https://protesilaos.com/emacs/modus-themes>
- Change log: <https://protesilaos.com/emacs/modus-themes-changelog>
- Colour palette: <https://protesilaos.com/emacs/modus-themes-colors>
- Sample pictures: <https://protesilaos.com/emacs/modus-themes-pictures>

It is still possible to open issues on either of the mirrors and I will
handle them in a timely fashion, though I encourage you to at least try
the mailing list workflow---it is ordinary email (just remember to
"reply to all").

Further reading that is relevant to SourceHut:

- Moving all my Emacs projects to SourceHut:
  <https://protesilaos.com/codelog/2022-04-07-all-emacs-projects-sourcehut/>

- Primer on formatting Git patches with Emacs (Magit):
  <https://protesilaos.com/codelog/2022-04-09-simple-guide-git-patches-emacs/>

Problems with byte compilation on Emacs 29
==========================================

For some time between mid-April to mid-May, users of Emacs 29 could not
byte compile the Modus themes.  This has now been fixed in emacs.git,
per bug#55414: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55414>.
Thanks to everyone involved (A-Z): Alan Mackenzie, Eli Zaretskii, Lars
Ingebrigtsen, Mattias Engdegård, Stefan Monnier.

Messages about invalid face attributes while using the centaur-tabs
===================================================================

I mentioned this issue in the previous change log as well: upstream does
not allow us to use indirection in faces (the ':inherit' attribute).
This is not our bug.  It is standard behaviour for themes to use
inheritance.

I have an open pull request on the matter (since 2022-02-24):
<https://github.com/ema2159/centaur-tabs/pull/179>.

Relevant reports:

- <https://github.com/protesilaos/modus-themes/issues/30>
- <https://gitlab.com/protesilaos/modus-themes/-/issues/288>
- <https://github.com/protesilaos/modus-themes/issues/15>

Support for new faces or face groups
====================================

Directly supported
------------------

These are packages whose faces we override to make them work with the
themes.

- 'calibredb'.  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 on the official mailing list:
  <https://lists.sr.ht/~protesilaos/modus-themes/%3C87zgkgroi7.fsf%40gmail.com%3E>.

  Ivan also introduced some new faces to 'calibredb', which I helped
  test.  See: <https://github.com/chenyanming/calibredb.el/pull/60>.

- 'ein' (Emacs IPython Notebook).  We support its code blocks with the
  appropriate colouration, while avoiding exaggerations.  Thanks to
  Maxime Tréca for the feedback in issue 31 over at the GitHub mirror:
  <https://github.com/protesilaos/modus-themes/issues/31>.

- 'tree-sitter'.  My intent was to reduce the overall colouration
  produced by the default 'tree-sitter' faces.  These tweaks give us
  good results, though there still are some cases where 'tree-sitter'
  exaggerates the styles it uses, such as by combining types with
  constants to produce ad-hoc (anonymous) faces.  We cannot do anything
  about anonymous faces at the theme level.  As such, we may get an
  additional bold weight (when 'modus-themes-bold-constructs' is
  non-nil) when we would rather not have it and/or a different colour
  than the one desired.

  Thanks to Przemysław Kryger for the feedback in issue 303 over at the
  GitLab mirror: <https://gitlab.com/protesilaos/modus-themes/-/issues/303>.

  If you are involved in the 'tree-sitter' project, please eliminate all
  anonymous faces and replace them with symbols (i.e. defface) that are
  editable by the user/theme.  You are welcome to contact me if you need
  help/ideas.

- 'vundo'

Indirectly supported
--------------------

These are packages that either (i) inherit from base faces we already
support, or (ii) use colours from the Modus themes' palette.  A list of
them is available in the manual.

- egerrit.  an in-development package by Niklas Eklund which provides an
  Emacs interface to Gerrit: <https://git.sr.ht/~niklaseklund/egerrit>.

Changes to supported face
=========================

- Reworked the internal functions that handle the styling of diffs to
  allow the user option 'modus-themes-deuteranopia' to combine with the
  styles of the 'modus-themes-diffs' option.

  Before, when 'modus-themes-deuteranopia' was non-nil it would affect
  diffs by forcibly applying the default style of 'modus-themes-diffs'
  (fairly prominent background colours) with the primary difference of
  replacing greens with blues.

  Now all combinations work as expected.  For example:

      (setq modus-themes-deuteranopia t
            modus-themes-diffs 'desaturated) ; nil, 'desaturated, 'bg-only

  Thanks to Kevin Le Gouguec for the feedback on the mailing list:
  <https://lists.sr.ht/~protesilaos/modus-themes/%3C878rqt4jhm.fsf@gmail.com%3E>

- Conducted a major (and highly demanding) review of the colours used by
  Avy in the interest of optimising the contrast between its constructs.
  Read the analysis: <https://protesilaos.com/codelog/2022-04-20-modus-themes-case-study-avy/>.

  Thanks to Daniel Mendler and Damien Cassou for their feedback on the
  mailing list:

  - <https://lists.sr.ht/~protesilaos/modus-themes/%3C83f18e2e-d726-0248-72f5-95e896cbcf4c%40daniel-mendler.de%3E>
  - <https://lists.sr.ht/~protesilaos/modus-themes/%3C87czhgt5nm.fsf%40cassou.me%3E>

- Updated the 'vertico-quick' faces to be consistent with Avy.

- Made the 'line-number' face conform with the user option
  'modus-themes-mixed-fonts'.  This means that if the user option is
  non-nil, line numbers of 'display-line-numbers-mode' will use a
  monospaced typeface at all times (inheriting the 'fixed-pitch' face,
  as explained in the themes' manual).  Otherwise they use whatever font
  the 'default' face has.  This makes it better when the user enables
  'variable-pitch-mode' but still wants spacing-sensitive constructs to
  remain monospaced.

  Thanks to Christopher League for the feedback in issue 302 over at the
  GitLab mirror: <https://gitlab.com/protesilaos/modus-themes/-/issues/302>.

- Aligned the regexp construct faces with the meaning of the user option
  'modus-themes-bold-constructs'.  They will use a bold weight only when
  the user option is non-nil.  This design is consistent with all other
  aspects of syntax highlighting.  These specific faces were
  unconditionally bold due to a mistake of mine.

  Remember to check the manual on what "a bold weight" means, as we make
  everything easy to customise (e.g. if you prefer a semibold weight):
  <https://protesilaos.com/emacs/modus-themes#h:2793a224-2109-4f61-a106-721c57c01375>.

- Removed the typographic emphasis from the 'file-name-shadow' face by
  no longer inheriting the 'italic' face.  Thanks to Nicolas De Jaeghere
  for the patch.

  [ Nicolas has assigned copyright to the Free Software Foundation. ]

- Stopped using the 'inverse-video' face attribute in 'powerline'.  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>.

- Ensured that git commit/rebase comments (as seen in the workflow of
  the 'magit' package) inherit from appropriate font-lock faces.  This
  makes it possible to customise 'font-lock-comment-face' and have the
  changes apply to those elements 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), making it look
  part of the comment block.

- Tweaked the 'fountain' package comments to be the same as all others.
  This avoids inconsistencies, such as when the user opts for something
  like the following:

      (setq modus-themes-syntax '(yellow-comments))

- Disabled padding in the 'keycast' package, meaning that the box around
  the key indicator always has the same height, even if the user opts
  for a padding value in 'modus-themes-mode-line' (read the manual or
  its doc string for how to assign a padding).

  This is in response to a change upstream that introduces the
  'keycast-tab-bar-mode', which re-uses the faces that were originally
  intended for the mode line in the tab-bar.  Ideally, upstream will
  provide distinct faces for each context so that we can have padding in
  the mode line but not the tab-bar.  However, I have not had the
  opportunity to suggest such a change and/or prepare the relevant patch
  (it is not straightforward).

- Refined some colour combinations for the "alternative syntax" style
  that is available when the user option 'modus-themes-syntax' includes
  the 'alt-syntax' property.  These tweaks pertain to changes in hue
  that improve the appearance of certain faces in their context.

- Enabled conditional use of 'fixed-pitch' for key bindings.  This
  happens when the user option 'modus-themes-mixed-fonts' is non-nil
  (all spacing-sensitive elements become monospaced even if the user
  opts for a default font that is proportionately spaced or activates
  the 'variable-pitch-mode').  Thanks to Manuel Giraud for the patch.

  [ Manuel has assigned copyright to the Free Software Foundation. ]

- Covered the face rotation option of 'highlight-changes-mode'.  It 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>

Updates to the manual
=====================

- Acknowledged Andrew Tropin as one of the contributors to the Guix
  package of the Modus themes.  The latest patch to that end:
  <https://issues.guix.gnu.org/55268>.

- Rewrote the note on 'fill-column-indicator' to show how the user can
  use a thicker line than the one we style by default.

- Wrote a note in manual about 'php-mode' multiline comments which use
  the 'font-lock-doc-face' instead of 'font-lock-comment-face'.  Sample
  code is provided to ensure consistency between all types of comments.

- Added note about custom 'hl-todo' colours, specifically the user
  option 'hl-todo-keyword-faces' (which the themes customise as an
  exception to the rule, otherwise the default colours would not always
  be accessible).

  This is in relation to the mailing list thread on the matter with
  feedback from Vincent Foley and Christian Tietze:
  <https://lists.sr.ht/~protesilaos/modus-themes/%3C871qwh1r88.fsf%40era.co%3E>.

- Elaborated on the style of 'git-gutter' faces in Doom Emacs, which are
  not as the Modus themes intend.  Basically, the problem is that Doom
  changes the way that package draws its bitmaps: the faces we configure
  no longer appear as intended and sensitive colouration is lost.

  Thanks to Gonçalo Marrafa for reporting the issue, testing the code we
  recommend on Doom Emacs, and suggesting the inclusion of the reference
  to the 'after!' call (a macro that Doom defines).

Miscellaneous
=============

- Dedicated the colours of the Modus themes---just the colours---to the
  public domain.  The Emacs package as a whole is still distributed
  under the terms of the GNU General Public License.  The announcement:
  <https://protesilaos.com/codelog/2022-05-10-modus-themes-palette-cc0/>

- Stopped using a timestamp in the modus-themes.el file.  It could lead
  to situations where there was a mismatch between the latest change and
  the recorded time.  It also introduced a barrier to entry for
  contributors, as they need to set up 'time-stamp.el'.

- Removed the unnecessary 'require' call to the 'seq' library and made
  the necessary changes.  Thanks to Daniel Mendler for the patch.

  [ Daniel has assigned copyright to the Free Software Foundation. ]

- Applied the correct order of inheritance for all markup faces.  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)'.

- Tweaked how 'org-date' conditionally uses 'fixed-pitch'.  Basically,
  we remove an internal stylistic inconsistency.  There is no
  user-facing change.  Thanks to Manuel Giraud for the patch.

- Implemented the command 'modus-themes-report-bug'.  It might help
  users find the email address of the mailing list and get started with
  the email-centric workflow of SourceHut.  Note this is but a first
  step in that direction.  If you think it can be improved, please
  report as much (or send a patch).

- Included the command 'modus-themes-version', which prints in the echo
  area the current version of the package.  With an optional prefix
  argument, it inserts the string at point.

  The version either is the last tagged release, such as '2.4.0', or an
  in-development version like '2.5.0-dev'.  As we use semantic
  versioning, tags of the '2.4.1' sort are not considered: those would
  count as part of '2.5.0-dev'.

Modus themes version 2.3.0

By Protesilaos Stavrou <info@protesilaos.com> on 2022-04-01

This entry documents the changes made to the project since the
publication of version 2.2.0 on 2022-02-23.  It spans more than 70
commits.

To access the URL of the manual visit:
<https://protesilaos.com/emacs/modus-themes>.  Or read it in the Emacs
Info reader by evaluating:

    (info "(modus-themes) Top")

The 'modus-operandi' and 'modus-vivendi' themes are built into Emacs-28
(next stable release) or later, and are available on GNU ELPA as well as
other archives.  Emacs-28 ships version 1.6.0, while the current
'master' branch (i.e. Emacs-29) and, by extension, GNU ELPA include the
latest tagged release.

Customisation options
=====================

* The 'modus-themes-completions' now accepts a 'text-also' property for
  the 'selection' key.  This has the effect of colourising the current
  line's text.  Whereas the default does not change the text colour,
  re-using whatever underlying colours are available.  Consult the doc
  string of this user option, as it provides for fine-grained control of
  how completion UIs may look.  Thanks to Morgan Willcock whose feedback
  in issue 278 inspired me to add the 'text-also' property:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/278>.

* The 'modus-themes-box-buttons' now accepts an 'all-buttons' property.
  It applies whatever other style is used for the boxed buttons to the
  generic 'widget.el'.  By default, the faces of 'widget.el' do not look
  like graphical buttons: they have a bold weight and a foreground
  colour instead.  Examples where those are used are the Notmuch "hello"
  buffer and the main view of the 'elfeed-summary' package.  Thanks to
  Daniel Mendler, Rudolf Adamkovič, and Tony Zorman for their feedback
  in issue 296: <https://gitlab.com/protesilaos/modus-themes/-/issues/296>.

* The 'modus-themes-intense-mouseovers' is a boolean user option which
  makes mouse hover effects more intense when set to a non-nil value.
  By default, mouseovers use a cyan background value.  This changes it
  to a more prominent blue.  Thanks to John Haman for the feedback in
  issue 290: <https://gitlab.com/protesilaos/modus-themes/-/issues/290>.

* The user options 'modus-themes-box-buttons', 'modus-themes-mode-line',
  'modus-themes-org-agenda', and 'modus-themes-headings' can now read a
  number value as a cons cell.  The old method of a plain number
  continues to work.  This makes it possible to be more descriptive on
  what a given value signifies.  Each doc string describes the
  technicalities.  Here are samples that yield identical results:

      (setq modus-themes-mode-line '(accented 0.9 borderless 2))
      (setq modus-themes-mode-line '(accented (heigh 0.9) borderless (padding 2)))

  Thanks to Daniel Mendler for proposing this idea in issue 282:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/282#note_842257619>

Attempted bug fix for byte compiled files
=========================================

Quoting from the git log:

    commit f067d2ef39c22174b95584f2cba7942aaf03bcca
    Author: Protesilaos Stavrou <info@protesilaos.com>
    Date:   Thu Mar 3 06:52:31 2022 +0200

        Reify themes with eval-and-compile

        This is an attempt to fix a bug that has existed since version 1.2.0 of
        the themes or even earlier.

        The bug is about a mismatch between compiled code and runtime
        dependencies.  The runtime expects the current version while the
        compiled code only furnishes an outdated one, thus resulting in an
        error.  This only happens when:

        1. Private functions change to accept more/fewer arguments.
        2. Variables change their acceptable value (e.g. from symbol to list).
        3. The user is installing the package via the package.el mechanism which
           takes care of byte compilation (though anything that mimics
           package.el should exhibit the same behaviour).

        My understanding is that the cause was the limited scope of the
        'eval-and-compile' we had before: it would run the 'require' also at
        compile time, whereas the 'modus-themes-theme' macro, which reifies the
        actual theme, would only be evaluated at runtime.  Hence the mismatch as
        'require' would read the already installed byte code while the macro
        would expect newer forms.

        Wrapping everything in the 'eval-and-compile' should address this
        problem.  Hopefully it will not engender new ones...

        * * *

        The latest reports about this bug:

        * GitLab issue 287 with Mark Bestley and Daniel Mendler:
          <https://gitlab.com/protesilaos/modus-themes/-/issues/287>.

        * GitHub issue 22 with Rytis Paškauskas:
          <https://github.com/protesilaos/modus-themes/issues/22>.

     doc/modus-themes.info   | 30 +++++++++++++++---------------
     doc/modus-themes.org    | 15 ++++++++-------
     modus-operandi-theme.el | 10 +++++-----
     modus-vivendi-theme.el  | 10 +++++-----
     4 files changed, 33 insertions(+), 32 deletions(-)

After nearly one month, no problem has been observed as a result of this
change.

Newly supported packages
========================

These are added to the already comprehensive coverage we guarantee.

Directly supported:

* devdocs.  Thanks to Augusto Stoffel, its developer, for the feedback
  which was sent via email.

* mini-modeline.  Thanks to Julio C. Villasante for the feedback in
  issue 24 over at the GitHub mirror:
  <https://github.com/protesilaos/modus-themes/issues/24>.

Indirectly supported (they use faces that we already cover):

* elfeed-summary
* undo-hl

Changes to supported faces or packages
======================================

* Improved the colours used by 'avy' to always guarantee constrast in
  hueness between side-by-side characters with a variety of user
  settings.  I tried various styles, such as:

      (setq avy-style 'pre)
      (setq avy-style 'at-full)

  For the sake of completeness, I also ran tests by modifying the
  'avy-lead-faces' (which is a 'defconst', not a 'defcustom'):

      (setq avy-lead-faces
            '(avy-lead-face
              avy-lead-face-0
              avy-lead-face-2
              avy-lead-face
              avy-lead-face-0
              avy-lead-face-2))

      (setq avy-lead-faces
            '(avy-lead-face
              avy-lead-face-1
              avy-lead-face-1
              avy-lead-face-1
              avy-lead-face-1))

      (setq avy-lead-faces
            '(avy-lead-face
              avy-lead-face-2
              avy-lead-face-2
              avy-lead-face-2
              avy-lead-face-2))

* Updated the 'vertico-quick' faces to keep them aligned with the new
  Avy styles.  Thanks to Daniel Mendler (Vertico's developer) for the
  reminder:
  <https://gitlab.com/protesilaos/modus-themes/-/commit/404a9658196debdde95a51148fc62c5b2faccfb9#note_856454659>.

* Applied warmer though still not saturated colours for Org clocking
  overlays.  The previous style could be mistaken for a mouse highlight
  or the highlighted line if 'modus-themes-hl-line' included the
  properties 'intense' and 'accented'.  Thanks to Rudolf Adamkovič for
  the feedback in issue 293:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/293>.

* Broadened coverage of the built-in 'shr.el' library to include the new
  'shr-code' face (Emacs 29).

* Expanded support for the 'embark' package by covering its new
  'embark-collect-marked' face.  Thanks to Daniel Mendler for the
  feedback in issue 299:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/299>.

* Made the 'fill-column-indicator' a contiguous line.  It was a dashed
  line before, per the Emacs defaults, which led to awkward results
  depending on the font family and value of 'line-spacing'.  Thanks to
  Daniel Mendler for the feedback in issue 297:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/297>.

* Added explicit support for the built-in 'separator-line' face in order
  to refine its presentation.  This is present in 'M-x shortdoc' buffers
  (Emacs 28).  Thanks to Daniel Mendler for the feedback in issue 297:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/297>.

* Applied explicit styling to the generic 'underline' face in order to
  ensure its consistent colouration.  The problem before was that an
  underline that spanned text with distinct colours would inherit the
  colour of the affected character.  A uniform presentation makes
  everything easier to read.

* The 'ement.el' Matrix client now uses a subtle background for username
  mentions and/or quoted text.  This is consistent with how other Matrix
  clients style such constructs.  Thanks to Adam Porter (aka
  "alphapapa"), the developer of ement.el, for explaining the
  technicalities and providing the relevant feedback in issue 25 over at
  the GitHub mirror: <https://github.com/protesilaos/modus-themes/issues/25>.

* Enforced consistency between 'icomplete' and 'ido'.  The first match
  was coloured differently in 'ido-mode' by mistake.  Thanks to Morgan
  Willcock for the feedback in issue 278:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/278>.

* Used the main foreground for Company's tooltip.  This is how it should
  have been.  Corfu is designed that way as well.  Thanks to user okamsn
  for the feedback in issue 278:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/278>.

* Corrected an omission whereby the AUCTeX verbatim face was not
  consistent with other such faces.  Now it too is governed by the user
  option 'modus-themes-markup'.

* Fixed the 'centaur-tabs' invalid background message.  Thanks to
  Lennart C. Karssen for reporting the bug in issue 288:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/288>.  Note,
  however, that the problem is due to some decisions made upstream.  My
  patch has not been merged yet (open since 2022-02-24):
  <https://github.com/ema2159/centaur-tabs/pull/179>.  Given this
  opportunity, always anticipate that faces may ':inherit' from others
  and thus functions like 'face-background' might return an undesirable
  nil value if used without a fallback.

Miscellaneous
=============

* Made the 'modus-themes--current-theme' return the first Modus theme
  instead of the 'car' of 'custom-enabled-themes'.  This makes the
  themes work at all times even when the user has multiple of them
  enabled.  Thanks to Pierre Téchoueyres for the patch, which was sent
  via email with regard to Emacs bug#54598:
  <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54598>.

* Implemented compile-time requirement for built-in libraries to be sure
  that the themes work in all cases.  Thanks to Antonio Hernández Blas
  for reporting in issue 292 the bug with the old design that assumed
  the 'cl-lib' and 'subr-x' as already loaded:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/292>.

* Wrote in the manual how to achieve a monochrome style (with
  permutations) for code syntax highlighting.  Thanks to Augusto Stoffel
  for sharing the idea via an email exchange (this information is
  divulged with permission).

* Clarified some statements in the manual's section about the nuances in
  "enabling" and "loading" a theme.

* Documented how the applicable palette affects the outer boundaries of
  the colour range that terminal emulators set when Emacs is ran without
  a GUI.  Here "the palette" refers to the relevant 16 ANSI escape
  sequences (terminal colours 0 through 15).  For the sake of
  convenience, the node includes ready-to-use palettes for XTerm, which
  can be adapted to other terminal emulators.  This entry complements an
  existing one on improving the colour accuracy in terminal emulators.

* Used American English constructions in a few places such as "color"
  instead of "colour" as that is what core Emacs expects (and the themes
  are part of emacs.git).

* Updated the description of the themes to be more user-friendly.
  Instead of "Highly accessible themes (WCAG AAA)" we now have "Elegant,
  highly legible and customizable themes".  Nothing changes in terms of
  substance.  Thanks to Jorge Morais for the feedback.

* Clarified that the version of the themes which is built into Emacs
  does not use 'require'.  It is in response to this thread:
  <https://lists.gnu.org/archive/html/help-gnu-emacs/2022-03/msg00049.html>.
  Thanks to Philip Kaludercic for bringing the issue to my attention.

* Improved the code samples that show how to set up the package.

* Wrote the correct symbols for some obsoletion forms.

Thanks once again to everyone involved!

Modus themes version 2.2.0

By Protesilaos Stavrou <info@protesilaos.com> on 2022-02-23

The present entry records the changes made to the project since the
publication of version 2.1.0 on 2022-02-17.  This spans about 10 commits
(though one of them is massive).  Normally the release cycle occurs over
periods of 4-5 weeks.  This is a necessary exception.

To access the URL of the manual visit this web page:
<https://protesilaos.com/emacs/modus-themes>.  Or read it in the Emacs
Info reader by evaluating this form:

    (info "(modus-themes) Top")

The 'modus-operandi' and 'modus-vivendi' themes are built into Emacs-28
(next stable release) or later, and are available on GNU ELPA as well as
other archives.  Emacs-28 ships version 1.6.0, while the current
'master' branch (i.e. Emacs-29) and, by extension, GNU ELPA include the
latest tagged release.

Initialisation of user options
==============================

Removed a superfluous default value that hampered the initialisation of
defcustom forms in the M-x customize interface.  Things would still
work, but the interface was not looking right while editing the relevant
variables.  Thanks to Gustavo Barros for reporting the bug in issue 267:
<https://gitlab.com/protesilaos/modus-themes/-/issues/267>.

Refactor 'modus-themes-completions'
===================================

Implemented thoroughgoing reforms across all completion User Interfaces
(UIs) in order to make them more flexible/powerful and harmonise their
looks.

'modus-themes-completions' now accepts an alist instead of a symbol.
Each cons cell is in the form of '(key . list-of-properties)'.  The doc
string describes all the details.

In terms of out-of-the-box appearences, all completion UIs have a subtle
aesthetic.  This was always the case for the likes of Vertico, Icomplete
(Fido), and related, though it constitutes a marked departure from what
Ivy and Helm used to look like.  Users of the latter two can still get
the more colourful or intense style with something like this:

    (setq modus-themes-completions '((matches . (background intense))
                                     (selection . (accented intense))
                                     (popup . (accented intense))))

Or simply:

    (setq modus-themes-completions '((t background intense accented)))

The documentation explains all those associations in-depth.  There also
are other styles on offer (and combinations thereof).

Furthermore, the new 'modus-themes-completions' encompasses more UIs
than its predecessor, including Company and Corfu.

In the interest of theme-wide consistency, all applicable faces have
been reviewed.

Finally, note that the previous tagged release also made changes on this
front, but it did not disrupt the status quo that was in place from
before the release of version 1.0.0 of the themes (more than a year
ago).  In other words, it tried to make unnecessary compromises within
the confines of an outdated design that did not fit in with the rest of
the code base.  The new 'modus-themes-completions' might require manual
intervention from users who want to customise things to their liking,
though I feel this change is to our long-term benefit.

Thanks to Daniel Mendler and Rudolf Adamkovič for their feedback in
issue 278: <https://gitlab.com/protesilaos/modus-themes/-/issues/278>.
And thanks to Kenta Usami for recommending the use of a warning in issue
286: <https://gitlab.com/protesilaos/modus-themes/-/issues/286>.

Miscellaneous changes
=====================

+ Removed the pseudo-button effect from the 'org-checkbox' face.  It was
  not up-to-date with the current style of the rest of the themes,
  including the Org constructs for source block delimiters, the TODO
  keywords, the priority cookies (e.g. '[#A]'), and others.

+ Introduced a section in the manual which provides an alternative to
  the standard 'modus-themes-toggle' that leverages 'enable-theme'
  instead of 'load-theme' under the hood.  These technicalities are all
  explained in the manual.

+ Provided an alternative greyscale palette subset for 'modus-operandi'
  in the manual's section about overriding colours.

+ Added support for the built-in 'custom-variable-obsolete' face.

+ Fixed typo in the 'modus-themes-box-buttons' variable.  Thanks to
  Illia Ostapyshyn for the patch in merge request 58:
  <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/58>.

Modus themes version 2.1.0

By Protesilaos Stavrou <info@protesilaos.com> on 2022-02-17

The present entry records the changes made to the project since the
publication of version 2.0.0 on 2021-12-24.  There have been more than
110 commits in the meantime (and this log is close to 5000 words).

All modifications of colour combinations mentioned herein are made in
accordance with the primary accessibility objective of the themes for a
minimum contrast ratio of 7:1 between background and foreground values
in their given combination (the WCAG AAA standard for relative colour
luminance).  Edits also account for colour-coding that is optimised for
the needs of users with red-green colour deficiency (deuteranopia).

To access the URL of the manual visit this web page:
<https://protesilaos.com/emacs/modus-themes>.  Or read it in the Emacs
Info reader by evaluating this form:

    (info "(modus-themes) Top")

The 'modus-operandi' and 'modus-vivendi' themes are built into Emacs-28
(next stable release) or later, and are available on GNU ELPA as well as
other archives.  Emacs-28 ships version 1.6.0, while the current
'master' branch (i.e. Emacs-29) and, by extension, GNU ELPA include the
latest tagged release.

Commands
========

The following produce a buffer that previews the colour palette of the
given theme ('modus-operandi' or 'modus-vivendi').

* 'modus-themes-list-colors' prompts for a theme before producing the
  preview.

* 'modus-themes-list-colors-current' uses the current Modus theme.

These commands are useful to anyone who wants to reference a named
colour from the themes or copy a colour value, such as for the purposes
of user-level customisation (as documented at length in the manual
across several use-cases and with the inclusion of custom code).

The commands are not bound to any key.

Customisation options
=====================

* Implemented the 'modus-themes-markup' variable, which supersedes the
  now-deprecated 'modus-themes-intense-markup'.  The new user option
  accepts a list of properties (symbols).  It affects constructs such as
  Org's =verbatim=, ~code~, and {{{macro}}}.  By default, when this user
  option is either nil or an empty list, the affected constructs only
  have a foreground colour (e.g. Org verbatim is magenta).  Properties
  that change this style are:

  1. 'italic' for an added slant to the text.
  2. 'bold' for a heavier weight.
  3. 'background' to add a background colour.
  4. 'intense' to amplify the colouration (especially of 'background').

  As with all user options which accept a list of properties, the order
  of the symbols is no significant.  In user configurations it may look
  like this:

      (setq modus-themes-markup '(background intense bold))

  [ Read the manual for bold and italic fonts.  We do not hardcode a
    :weight or :slant, instead giving the user the option to set their
    own values.  The defaults are what you would normally expect from
    "bold" and "italic". ]

  Thanks to Rudolf Adamkovič for reporting some problems with the old
  design in issue 274:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/274>.

* Added the 'modus-themes-box-buttons' which affects all pseudo
  graphical buttons, such as those found in Custom UI buffers or EWW web
  pages which include search forms and the like.  The variable accepts a
  list of properties as its value.  By default (nil or empty list),
  buttons have a grey background and the familiar 3D effect.  Valid
  properties are:

  1. 'flat' to remove the 3D effect.
  2. 'accented' to shift the colouration away from grey.
  3. 'faint' to reduce the overall colouration (e.g. grey becomes white).
  4. 'variable-pitch' to apply a proportionately spaced font.
  5. 'underline' to draw a line instead of applying a 3D or flat box
     (particularly useful for those who use Emacs in a terminal emulator).
  6. The symbol of a font weight, such as 'bold', 'semibold', 'light' or
     any one among those included in the 'modus-themes-weights' constant
     (the underlying font family has to support the given weight).
  7. A number, expressed as a floating point (e.g. 0.9), which adjusts
     the height of the button’s text to that many times the base font
     size.  The default height is the same as 1.0, though it need not be
     explicitly stated.

  The order in which those symbols appear in the list is not
  significant.  If 'underline' and 'flat' are both specified, the former
  takes precedence.  In user init files the form may look like this:

    (setq modus-themes-box-buttons '(variable-pitch flat semilight 0.9))

  Thanks to Daniel Mendler for suggesting this user option and providing
  the relevant feedback in issue 282:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/282>.

* Expanded the 'modus-themes-mail-citations' with an 'intense' variant.
  For example:

      (setq modus-themes-mail-citations 'intense)

  The default is a moderately coloured style.  Other variants include
  'faint' for subtle colouration and 'monochrome' for an all-grey look.

* Reviewed the 'modus-themes-completion' option and harmonised all the
  face specifications it governs.  The variable now accepts a fourth
  stylistic variant in 'super-opinionated': it is like the 'opinionated'
  one though some details are even more pronounced.  Other noteworthy
  items:

  [ Remember to read the doc string of 'modus-themes-completions', which
    explains the grouping of the completion UIs. ]

  - The (setq modus-themes-completions 'moderate) style is more-or-less
    the same across all completion UIs.  The highlight applied to the
    current line is a bespoke shade of blue, the characters are less
    saturated than before and their hues are different, though the
    overall effect should still feel "sufficiently colourful, but not
    overdone".

  - The (setq modus-themes-completions nil) is the same as before.
    However:

      - The current line in Ivy now uses a shade of blue that is
        specific to completion UIs instead of an intense cyan
        background.  This is for theme-wide consistency.

      - Helm's current line has the same bespoke blue for its current
        line instead of another shade of blue it was using before.

  - The (setq modus-themes-completions 'opinionated) should be the same
    as before, notwithstanding the aforementioned tweaks to Ivy/Helm.

  - The (setq modus-themes-completions 'super-opinionated) for
    Icomplete, Vertico, Selectrum, Mct uses the same blue for the
    current line as is the default of Ivy and Helm.

  Miscellaneous:

  - The relevant private helper functions were rewritten.

  - We declare a few faces to help streamline certain styles.

  - Ivy action keys now inherit from 'modus-themes-key-binding'.  We
    generally try to make all keys look the same, except when that would
    be detrimental to the usability of the given context/interface.

  - Some Ivy faces are simplified or otherwise tweaked to fit in with
    the rest of the theme.

  Thanks to Rudolf Adamkovič for the feedback about Vertico in issues
  214 and 278 which prompted me to review all completion UIs:

  - <https://gitlab.com/protesilaos/modus-themes/-/issues/214>
  - <https://gitlab.com/protesilaos/modus-themes/-/issues/278>

* Adjusted the applicable hues in some 'modus-themes-syntax' variants.  In
  particular:

  - The strings' hue has more hints of blue when 'modus-themes-syntax'
    includes the 'green-strings' property.  Such as:

      (setq modus-themes-syntax '(green-strings))
      (setq modus-themes-syntax '(alt-syntax green-strings))
      (setq modus-themes-syntax '(alt-syntax green-strings faint))
      (setq modus-themes-syntax '(alt-syntax green-strings faint yellow-comments))

  - Strings are more orange/yellow than red when 'modus-themes-syntax'
    includes the 'alt-syntax' property but NOT the 'green-strings'.  For
    example:

      (setq modus-themes-syntax '(alt-syntax))
      (setq modus-themes-syntax '(alt-syntax yellow-comments))
      (setq modus-themes-syntax '(alt-syntax yellow-comments faint))

  - Backslashes for regexp constructs are coloured appropriately to look
    distinct from the rest of the string and from the escaped construct in
    all cases.

* Removed background colours from the the default style of Org block
  delimiters.

  As I explained in Emacs bug#52587,[1] Org has code that overrides
  themes which prefer not to extend the block delimiter faces to the
  edge of the window (as we would like to do by default).  This
  practically means that we cannot have backgrounds for those lines and
  keep them limited to the stretch of area covered by their text.

  As such, the default for Org block delimiter lines now is a gray
  foreground with no distinct background colour.  The user option
  'modus-themes-org-blocks' provides "blocky" alternatives that use
  background colours---those extend to the edge of the window.

  [1] <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52587#46>

* Deleted the compatibility layer for all user options that used to
  accept symbols in the past but now expect a list of symbols.  The
  manual contains a snippet with all customisation options for those who
  do not want to read all the relevant doc strings.  Evaluate this:

      (info "(modus-themes) Customization Options")

  Or visit: <https://protesilaos.com/emacs/modus-themes#h:bf1c82f2-46c7-4eb2-ad00-dd11fdd8b53f>.

  The original plan was to remove those during the transition to version
  2.0.0 (about a month ago) though I changed my mind thinking they would
  not pose a longer-term problem.

  New information by Mark Bestley in issue 272 shows that this kind of
  complexity can lead to errors:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/272#note_826725412>.

  So it is better to keep things simple and ask users to configure all
  user options based on the up-to-date documentation.

  Also thanks to Saša Janiška for the feedback in issue 272.

New packages, faces, or face groups
===================================

* all-the-icons-dired.

* all-the-icons-ibuffer.

* 'child-frame-border' face (Emacs 28).

* 'citar' package.  Thanks to Rudolf Adamkovič for the feedback in issue
  280: <https://gitlab.com/protesilaos/modus-themes/-/issues/280>.

* 'elisp-shorthand-font-lock-face' (Emacs 29).  Read the manual by
  evaluating:

      (info "(elisp) Shorthands")

* 'ement' (ement.el) Matrix client, though it is not listed in any
  archive yet: <https://github.com/alphapapa/ement.el>.

  Thanks to Samuel Culpepper for the feedback in issue 279:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/279>.

  Also check the Ement issue tracker on the matter:
  <https://github.com/alphapapa/ement.el/issues/53>.

* 'mct' package.

* 'menu' face (built-in) which is used in the menu-bar when Emacs runs
  without a graphical toolkit.

* 'pgtk-im-0' face (Emacs 29).  This is shown as a single-character-long
  block when you type the Compose key followed by the composable
  characters.

* 'pyim' (an input method for CJK characters).  Thanks to Yuanchen Xie for
  the contribution in merge request 57:
  <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/57>.
  The patch is small and is thus excluded from the requirement for
  copyright assignment to the FSF (remember that the themes are built
  into Emacs and any major contribution needs such copyright
  assignment---read the relevant entry in the themes' manual).

* 'slime' and 'sly' packages.  Thanks to John Haman for the feedback
  which was done via email due to some problems with the web UI on
  GitLab (this information is shared with permission).  Please note that
  I am not familiar with Common Lisp and could not test these
  thoroughly.  Any mistakes or omissions are my own.

  Concerning the web UI, there is a fully functional mirror of the
  themes on GitHub, while email is always an option.  Use whatever works
  for you to report an issue or send a patch.

* 'textsec' package (Emacs 29).

New indirectly supported packages
---------------------------------

These inherit from base faces and look good enough already or use
appropriate colours from the Modus themes:

* dtache
* org-remark

Changes to supported faces or face groups
=========================================

* Stopped making key bindings look like boxes.  We revert to the old
  style we were using before the introduction of the 'help-key-binding'
  face (Emacs 28).

  By default Emacs 28 or higher will render all key bindings it
  identifies with a box around them.  The idea is to make them look like
  keys on a keyboard, which I never really liked because without
  generous padding you get a very tight space between the character and
  the box's borders which can look weird at small point sizes (Emacs
  faces do not have padding in the same way CSS does).

  I tried following the default style for a few months and have concluded
  that it is not good enough for our purposes (my preferences
  notwithstanding):

  - The box attribute does not work in terminal emulators.  This means
    that keys only get a subtle grey background and the default
    foreground, which can be hard to make them stand out from their
    surrounding text if the font height is small and/or the keybinding is
    short (e.g. a single character).

  - The box and grey background combination limits our options when we
    need to colour-code different types of keys.  For example, the
    'which-key' package can show TAB as T and applies to it a different
    face to make the distinction obvious.  In that case, the presence of
    the tight box makes the use of a bold weight inappropriate: the
    character and the box's borders seem to overlap.  While the grey
    background limits our choice of colour as, for instance, yellow
    never looks good against it.  Same principle for interfaces that can
    have colour-coded keys like 'transient' and 'hydra', where we lose
    much-needed flexibility.

* Adjusted the brightness of the 'which-key-special-key-face'.  This is
  the face that applies to special keys.  For example:

      (setq which-key-special-keys '("SPC" "TAB" "RET" "ESC" "DEL"))

* Made 'transient' faces which are supposed to be de-emphasise certain
  elements inherit the 'shadow' face.  This is an implicit customisation
  option, as it allows the user to adjust the foreground value of all
  "less important" constructs simply by changing the 'shadow' face.

* Covered the 'transient-purple' face (these are like the colour-coding
  of 'hydra').

* Tweaked the 'transient-argument' and 'transient-value' faces to make
  things look a bit more consistent with the other transient faces.
  This is to avoid potential conflicts with the highlighted key
  bindings, especially when transient uses hydra-style colour-coded
  keys.

* Applied the same metaphors for key bindings to 'marginalia-key'
  ('marginalia' package) and 'embark-keybinding' ('embark' package).
  They inherit the 'modus-themes-key-binding' when possible.  The only
  exception is with (setq modus-themes-completions nil) where conflicts
  may arise between the key's style and matching characters of the
  ongoing completion session.

  Thanks to Rudolf Adamkovič for pointing out the inconsistency in issue
  278: <https://gitlab.com/protesilaos/modus-themes/-/issues/278>.

* Refrained from treating LaTeX sections as headings.  This is because
  unlike Org/Outline/Markdown Latex is basically source code, so the
  sectioning does not work the same way it does for those lightweight
  markup/outlining modes.

  Furthermore, font-latex.el defines 'font-latex-fontify-sectioning'
  which can be used to control the scale of those sections.  It makes
  sense for the themes to not interfere with that design and just allow
  users to customise things uniformly regardless of the active theme.

  Thanks to Gustavo Barros for the detailed feedback in issue 265:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/265>.

* Reviewed the hues of 'all-the-icons' and related packages.

* Applied the correct style to 'info-menu-header', meaning that it now
  only uses a bold weight as it is not a real heading, instead of being
  affected by the user option 'modus-themes-headings'.

* Included new 'telega-entity-type-spoiler' face.  Thanks to bit9tream
  for informing me about it in issue 271:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/271>.  The
  conclusion:

      Tricky though perhaps dull

      I understand this is not an interesting topic and it probably is
      too difficult to relate to the various data points without
      visualising them and comparing the before and after
      states. Furthermore, data can be deceptive and I have always
      maintained that theme development stands at the intersection of
      science and art (at least for the purposes of conforming with the
      rigorous accessibility standards of the Modus themes).

      That granted, I wanted to shed light on the “behind the scenes”
      work that is not immediately obvious when one checks a diff that
      introduces some seemingly trivial tweaks like '#49d239'->'#49c029'
      or '#7fcfff'->'#8fbfff'.

* Tweaked the hues of all graph colours, which are used in the
  'org-habit' table.  The changes are subtle and should improve the
  overall usability of the graph.  For the technicalities, read:
  <https://protesilaos.com/codelog/2022-01-02-review-modus-themes-org-habit-colours/>.

  Also thanks to Rudolf Adamkovič for reporting the problem with white
  text on yellow background in issue 270:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/270>.

* Styled the 'markdown-highlighting-face'.  This is the face used for
  text in between double equals signs when the user option
  'markdown-enable-highlighting-syntax' is non-nil.

* Amplified the overall colouration of Eldoc's current argument.  It is
  a yellow foreground with a tinted background.  The blue foreground
  which was applied before could be hard to tell apart in some cases,
  especially because it is a common colour that is used elsewhere in the
  themes.  Whereas the warmer hues are easier to discern, especially
  while relying only on peripheral vision.

  Thanks to Rudolf Adamkovič for the feedback in issue 275:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/275>.

* Instructed Geiser to use the same style for its argument as Eldoc
  (edited the faces 'geiser-font-lock-autodoc-current-arg' and
  'geiser-font-lock-autodoc-identifier').

* Made the 'keycast-key' face work when 'modus-themes-mode-line' has a
  padding value (read the latter doc string or consult the manual).

* Refined the 'magit' faces for bisect, reflog, sequence, and signature
  views.  They get a bold weight and, where appropriate, are made to
  comply with the 'modus-theems-deueteranopia' option (meaning that
  greens turn into blues).

* Recoloured 'elfeed' tags from a shade of cyan to magenta, in the
  interest of theme-wide consistency but also to make them easier to
  tell apart from the name of the feed.  Also updated the faces used in
  the header-line to look better in context.

* Removed the hardcoded ':slant italic' from the 'italic' face, which is
  consistent with how we do not hardcode ':weight bold' in the 'bold'
  face.

  Such a design allows users to configure those faces and have the
  desired slant/weight (and even font family) apply consistently
  throughout the theme.  Read the manual for further details:
  <https://protesilaos.com/emacs/modus-themes#h:2793a224-2109-4f61-a106-721c57c01375>.

  Thanks to user derek-upham for pointing out the inconsistency in issue
  21 over at the GitHub mirror:
  <https://github.com/protesilaos/modus-themes/issues/21>.

* Improved the styles that apply to compilation buffers and related.
  The overarching intent was to reduce the excess colouration, without
  upsetting expectations and affecting the overall presentation.

  Thanks to Rudolf Adamkovič for the feedback in issue 277:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/277>.

  Note that compilation buffers apply an underline by default.  The
  manual explains how to change that:
  <https://protesilaos.com/emacs/modus-themes#h:420f5a33-c7a9-4112-9b04-eaf2cbad96bd>.

* Ensured a consistent style for the 'highlight' face across all
  contexts (typically used for mouse hover effects).  The mode line has
  an exception when its style includes an accented background (per
  'modus-themes-mode-line').

  Thanks to Rudolf Adamkovič for the feedback in issue 214:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/214>.

* Changed the foreground of 'mode-line-emphasis' from blue to purple, in
  order to avoid potential (albeit unlikely) confusion with other
  indicators.

* Desaturated the 'man' and 'woman' foreground value of the bold
  constructs and tweaked other faces to avoid potential inconsistencies.
  Thanks to Daniel Mendler for the feedback:
  <https://gitlab.com/protesilaos/modus-themes/-/commit/8080eb1c6c0020ba82e8abaa933d6686327bc616#note_841424489>.

* Removed certain exaggerations from widgets as seen in the Custom UI
  and EWW.  Specifically:

  - 'widget-field' does not need to ':extend', as that typically does
    not look good.

  - 'custom-state' gets a warmer colour to convey its message more
    effectively.

  - 'eww-form-text' no longer uses a ':box' because that breaks when the
    widget occupies more than one line.

  - 'eww-form-textarea' can now inherit from 'eww-form-text'.

  Thanks to Daniel Mendler for the feedback on the style of those faces in
  issue 284: <https://gitlab.com/protesilaos/modus-themes/-/issues/284>.

The manual
==========

* Clarified the wording of 'shr' fonts, which affect 'eww', 'elfeed',
  'ement', and possibly others.

* Wrote section on custom Org emphasis faces.  It includes code samples.

* Answered a Frequently Asked Question on whether the Modus themes are
  "colour schemes"---they are not and it is important to understand why.

* Addressed another Frequently Asked Question about porting the themes
  to other platforms or editors.  Relevant blog posts which explain how
  complex the issue is and why porting requires the same attention to
  detail as this project:

  - <https://protesilaos.com/codelog/2022-01-03-modus-themes-port-faq/>.
  - <https://protesilaos.com/codelog/2022-01-23-base16-modus-themes/>.

* Improved the sample code in the section about the backdrop of PDF
  files while using 'pdf-tools'.  Thanks to Utkarsh Singh for the patch,
  which was sent via email.

* Provided sample code on an alternative style for Ediff.

  There was a discussion with Philip Kaludercic in issue 273 about making
  this a defcustom: <https://gitlab.com/protesilaos/modus-themes/-/issues/273>.

  I first entertained the notion and did set up a branch for testing
  purposes.  However, I ultimately decided that such a course of action
  would establish a bad precedent because then every conceivable stylistic
  tweak could, in principle, become a user option.  Furthermore, the
  potential defcustom would introduce too much complexity as Ediff would
  have to continue to behave as other diffs (per 'modus-themes-diffs') if
  the user did not want the alternative style.

  As such, documenting how a user can achieve this is the right choice.

* Fixed internal link in the manual.  Thanks to Rudolf Adamkovič for
  reporting the problem in issue 277:
  <https://gitlab.com/protesilaos/modus-themes/-/issues/277>.

Miscellaneous
=============

* Covered workaround for improving the accuracy of colour reproduction
  in terminal emulators.  The results are still not as good as the
  graphical version of Emacs, though they are considerably better than
  before.  Thanks to gitrj95's issue 18 at the GitHub mirror, which
  prompted me to research this topic:
  <https://github.com/protesilaos/modus-themes/issues/18>.

* Helped report a bug in the PGTK build of Emacs where a new emacsclient
  window with the 'modus-vivendi' face would not show the cursor:
  <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53073>.  Thanks to
  contributed to the discussion on issue 7 over at the GitHub mirror:
  <https://github.com/protesilaos/modus-themes/issues/7>

* Shifted the hue of the intense 'hl-line' from a grey-cyan to a more
  vivid blue by reducing the relative contribution of the green channel
  of light.

  The change affects these styles:

      (setq modus-themes-hl-line '(accented intense))
      (setq modus-themes-hl-line '(accented intense underline))

  Thanks to Rudolf Adamkovič for suggesting a more vivid colour in issue
  214: <https://gitlab.com/protesilaos/modus-themes/-/issues/214>.

* Recalibrated the 'modus-vivendi' named colour 'bg-paren-match'.

  I wanted to increase its distance relative to the main background,
  just to be sure that it is easier to spot.  This is achieved by moving
  the hueness from the yellow to the magenta side of the spectrum.

  Overall, the change is subtle and has no major impact on the contrast
  ratio relative to the main background and foreground (we need to
  consider both due to the specifics of show-paren-mode (and related)).

  The results (#5f362f is the old, #6f3355 the new):

      |         | #000000 | #ffffff | #000000 | #ffffff |
      |---------+---------+---------+---------+---------|
      | #5f362f |    2.06 |   10.22 |   37904 |  333060 |
      | #6f3355 |    2.28 |    9.21 |   58282 |  291037 |

  The TBLFM formula for this table (org-mode notation):

      $2='(Λ $1 @1$2);%.2f :: $3='(Λ $1 @1$3);%.2f :: $4='(Δ $1 @1$4) :: $5='(Δ $1 @1$5)

  The Greek letters mean:

      (defalias 'Λ #'modus-themes-contrast)
      (defalias 'Δ #'color-distance)

* Expanded the "special" subset of the palette with faint variants of
  the four backgrounds.  These are reserved for special circumstances,
  as the name implies.  Below are the contrast values (see
  'modus-themes-contrast').

      Modus Operandi main accept colours against faint special backgrounds:

      |         | #f0f1ff | #ebf5eb | #fef2ea | #faeff9 |
      |---------+---------+---------+---------+---------|
      | #a60000 |    7.15 |    7.17 |    7.29 |    7.16 |
      | #972500 |    7.26 |    7.28 |    7.40 |    7.28 |
      | #a0132f |    7.13 |    7.15 |    7.27 |    7.14 |
      | #7f1010 |    9.44 |    9.47 |    9.63 |    9.47 |
      | #702f00 |    8.94 |    8.97 |    9.12 |    8.96 |
      | #7f002f |    9.64 |    9.67 |    9.83 |    9.66 |
      | #005e00 |    7.20 |    7.23 |    7.34 |    7.22 |
      | #315b00 |    7.13 |    7.15 |    7.27 |    7.15 |
      | #145c33 |    7.18 |    7.20 |    7.32 |    7.20 |
      | #104410 |   10.09 |   10.12 |   10.29 |   10.12 |
      | #30440f |    9.56 |    9.59 |    9.75 |    9.58 |
      | #0f443f |    9.76 |    9.79 |    9.96 |    9.79 |
      | #813e00 |    7.14 |    7.17 |    7.28 |    7.16 |
      | #70480f |    7.14 |    7.17 |    7.28 |    7.16 |
      | #863927 |    7.13 |    7.15 |    7.27 |    7.15 |
      | #5f4400 |    8.10 |    8.12 |    8.26 |    8.12 |
      | #5d5000 |    7.17 |    7.19 |    7.31 |    7.19 |
      | #5e3a20 |    8.91 |    8.94 |    9.09 |    8.93 |
      | #0031a9 |    9.31 |    9.34 |    9.49 |    9.33 |
      | #2544bb |    7.14 |    7.16 |    7.28 |    7.16 |
      | #0000c0 |   10.64 |   10.67 |   10.85 |   10.66 |
      | #003497 |    9.66 |    9.70 |    9.86 |    9.69 |
      | #0f3d8c |    9.06 |    9.09 |    9.24 |    9.09 |
      | #001087 |   13.15 |   13.20 |   13.42 |   13.19 |
      | #721045 |    9.99 |   10.02 |   10.19 |   10.01 |
      | #8f0075 |    7.72 |    7.75 |    7.88 |    7.74 |
      | #5317ac |    8.98 |    9.01 |    9.16 |    9.00 |
      | #752f50 |    8.22 |    8.25 |    8.38 |    8.24 |
      | #7b206f |    8.22 |    8.25 |    8.38 |    8.24 |
      | #55348e |    8.26 |    8.29 |    8.42 |    8.28 |
      | #00538b |    7.18 |    7.20 |    7.32 |    7.19 |
      | #30517f |    7.18 |    7.20 |    7.32 |    7.20 |
      | #005a5f |    7.13 |    7.15 |    7.27 |    7.15 |
      | #005077 |    7.76 |    7.79 |    7.91 |    7.78 |
      | #354f6f |    7.49 |    7.52 |    7.64 |    7.51 |
      | #125458 |    7.69 |    7.72 |    7.85 |    7.71 |

      Modus Vivendi main accept colours against faint special backgrounds:

      |         | #0e183a | #001f1a | #241613 | #251232 |
      |---------+---------+---------+---------+---------|
      | #ff8059 |    7.01 |    7.01 |    7.07 |    7.00 |
      | #ef8b50 |    7.01 |    7.00 |    7.07 |    7.00 |
      | #ff9077 |    7.85 |    7.85 |    7.93 |    7.85 |
      | #ffa0a0 |    8.91 |    8.91 |    9.00 |    8.91 |
      | #f5aa80 |    9.04 |    9.04 |    9.13 |    9.04 |
      | #ff9fbf |    9.06 |    9.05 |    9.14 |    9.05 |
      | #44bc44 |    7.04 |    7.04 |    7.11 |    7.04 |
      | #70b900 |    7.13 |    7.13 |    7.20 |    7.12 |
      | #00c06f |    7.24 |    7.24 |    7.31 |    7.24 |
      | #78bf78 |    7.87 |    7.86 |    7.94 |    7.86 |
      | #99b56f |    7.60 |    7.59 |    7.67 |    7.59 |
      | #88bf99 |    8.23 |    8.22 |    8.30 |    8.22 |
      | #d0bc00 |    8.98 |    8.98 |    9.07 |    8.98 |
      | #c0c530 |    9.31 |    9.31 |    9.40 |    9.30 |
      | #d3b55f |    8.71 |    8.71 |    8.79 |    8.71 |
      | #d2b580 |    8.81 |    8.80 |    8.89 |    8.80 |
      | #cabf77 |    9.28 |    9.27 |    9.36 |    9.27 |
      | #d0ba95 |    9.20 |    9.20 |    9.29 |    9.20 |
      | #2fafff |    7.18 |    7.18 |    7.25 |    7.18 |
      | #79a8ff |    7.32 |    7.32 |    7.39 |    7.31 |
      | #00bcff |    7.96 |    7.96 |    8.04 |    7.96 |
      | #82b0ec |    7.74 |    7.74 |    7.81 |    7.74 |
      | #a0acef |    7.97 |    7.96 |    8.04 |    7.96 |
      | #80b2f0 |    7.89 |    7.88 |    7.96 |    7.88 |
      | #feacd0 |    9.94 |    9.93 |   10.03 |    9.93 |
      | #f78fe7 |    8.29 |    8.29 |    8.37 |    8.29 |
      | #b6a0ff |    7.82 |    7.81 |    7.89 |    7.81 |
      | #e0b2d6 |    9.51 |    9.50 |    9.60 |    9.50 |
      | #ef9fe4 |    8.88 |    8.88 |    8.96 |    8.87 |
      | #cfa6ff |    8.72 |    8.71 |    8.80 |    8.71 |
      | #00d3d0 |    9.28 |    9.27 |    9.36 |    9.27 |
      | #4ae2f0 |   11.09 |   11.09 |   11.20 |   11.09 |
      | #6ae4b9 |   11.08 |   11.07 |   11.18 |   11.07 |
      | #90c4ed |    9.34 |    9.34 |    9.43 |    9.33 |
      | #a0bfdf |    9.10 |    9.09 |    9.18 |    9.09 |
      | #a4d0bb |   10.18 |   10.17 |   10.27 |   10.17 |

* Add docs on color overrides through blending.  Thanks to Alex Griffin
  for the contribution in issue 269 and the subsequent patch in merge
  request 56 (the patch is exempt from copyright assignment):

  - <https://gitlab.com/protesilaos/modus-themes/-/issues/269>.
  - <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/56>.

* Fixed typo in the ':group' value of some faces defined in
  modus-themes.el.  Thanks to Gustavo Barros for reporting it in issue
  266: <https://gitlab.com/protesilaos/modus-themes/-/issues/266>

* Updated copyright statement in all .el files to use the same wording
  as all other files that are built into Emacs.

* Made all sorts of tweaks and refinements to doc strings and nodes in the
  manual.

Thanks again to everyone involved!  This has been yet another cycle of
intense work which further iterated on an already solid base.