-
-
-
3.0.00bf40959 · ·
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. -
2.7.01d55785a · ·
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>. -
2.6.0976f52b3 · ·
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. -
2.5.064f9378a · ·
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). -
-
2.4.0191f2a68 · ·
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'. -
-
-
-
2.3.0f9b2c8b6 · ·
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! -
2.2.07b203db9 · ·
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>. -
2.1.01c777649 · ·
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. -
-
2.0.0e02480f0 · ·
Modus themes version 2.0.0 By Protesilaos Stavrou <info@protesilaos.com> on 2021-12-24 This entry covers the changes made to the project since the publication of version 1.7.0 on 2021-11-18. There have been more than 90 commits in the meantime. This is a major upgrade with some backward-incompatible changes, even though most work was done behind the scenes (i.e. not in git commits but local testing) to guarantee the relevance of all user-facing styles, code practices, et cetera. 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. A fully fledged org-mode file with the annotated task list for Modus themes version 2.0.0 is supplied as complementary material to the present entry. It should be annexed below this text on the announcement page: <https://protesilaos.com/codelog/2021-12-24-modus-themes-2-0-0/>. Customisation options ===================== There are some breaking changes that were necessary to improve the code base and make things easier as well as more efficient for end users. Please read carefully and apologies in advance for whatever inconvenience. * The 'modus-themes-variable-pitch-headings' no longer has any effect. Instead, users can specify a 'variable-pitch' property to the list they pass to the 'modus-themes-headings' or 'modus-themes-org-agenda' (examples below). * All 'modus-themes-scale-*' options are removed. Scaling of headings is now handled directly by the user options 'modus-themes-headings' and 'modus-themes-org-agenda' (code samples below). * The 'modus-themes-headings' option now accepts a floating point (see function 'floatp') that represents the multiplier relative to the base font size. This can be used to scale headings accordingly. Since this option can target individual heading levels (for 1 through 8), users can now implement their desired scale with greater precision. Whereas before it was limited to the first four levels, admittedly for no good reason. The newly introduced 'variable-pitch' property can also be applied on a per-level basis (making it easy to combine with existing properties, such as a custom weight, for maximum control). Example: ;; This is an alist: read the manual or its doc string. (setq modus-themes-headings '((1 . (variable-pitch light 1.6)) (2 . (overline semibold 1.4)) (3 . (monochrome overline 1.2)) (4 . (overline 1.1)) (t . (rainbow 1.05)))) * The 'modus-themes-org-agenda' follows the same design as the 'modus-themes-headings' where appropriate. Headings that can be scaled accept a floating point, while those that may be rendered in a proportionately spaced font accept the 'variable-pitch' property. In addition, a custom font weight is also supported in the relevant places (just as with 'modus-themes-headings'). Overall, the interface can now be tailored to the user's preferences with greater precision. ;; This is an alist: read the manual or its doc string. (setq modus-themes-org-agenda '((header-block . (variable-pitch light 1.6)) (header-date . (bold-today grayscale underline-today 1.2)) (event . (accented varied)) (scheduled . uniform) (habit . traffic-light))) * The 'modus-themes-scale-small' that was used in the Org agenda interface has been removed. No replacement is provided, as the downsizing had the undesired effect of breaking the otherwise neat alignment of elements on the grid. * The 'modus-themes-mode-line-padding' option has been removed. Instead, users can specify a natural number (positive integer) directly in the list of properties passed to the 'modus-themes-mode-line' variable. This has no effect when the 'moody' property is also set, because the Moody library applies its own padding. For example: (setq modus-themes-mode-line '(borderless accented 4)) Though not related to changes on our end, users of Emacs 29 must now set 'x-use-underline-position-properties' to nil for padding to work properly (due to other adjustments upstream). This relates to Emacs bug#52324 we had reported: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52324>. * All deuteranopia styles are consolidated in a single toggle: 'modus-themes-deuteranopia'. The 'modus-themes-success-deuteranopia' is thus rendered obsolete and superseded, while the individual deuteranopia-friendly styles for diffs ('modus-themes-diffs') and the Org agenda's habit graph ('modus-themes-org-agenda') are altogether removed. As opposed to top-level forms, there is no clean way to notify the user of the deprecation of individual values of a user option. * The "foreground only" style has been altogether removed from the user option 'modus-themes-diffs'. It never was up to the aesthetic standard of the themes even though the colours met the minimum 7:1 contrast ratio. There is a new section in the manual which documents how to implement such a style with user-level configurations. Short version: (defun my-modus-themes-custom-faces () (modus-themes-with-colors (custom-set-faces `(modus-themes-diff-added ((,class :background unspecified :foreground ,green))) ; OR ,blue for deuteranopia `(modus-themes-diff-changed ((,class :background unspecified :foreground ,yellow))) `(modus-themes-diff-removed ((,class :background unspecified :foreground ,red))) `(modus-themes-diff-refine-added ((,class :background ,bg-diff-added :foreground ,fg-diff-added))) ;; `(modus-themes-diff-refine-added ((,class :background ,bg-diff-added-deuteran :foreground ,fg-diff-added-deuteran))) `(modus-themes-diff-refine-changed ((,class :background ,bg-diff-changed :foreground ,fg-diff-changed))) `(modus-themes-diff-refine-removed ((,class :background ,bg-diff-removed :foreground ,fg-diff-removed))) `(modus-themes-diff-focus-added ((,class :background ,bg-dim :foreground ,green))) ; OR ,blue for deuteranopia `(modus-themes-diff-focus-changed ((,class :background ,bg-dim :foreground ,yellow))) `(modus-themes-diff-focus-removed ((,class :background ,bg-dim :foreground ,red))) `(modus-themes-diff-heading ((,class :background ,bg-alt :foreground ,fg-main))) `(diff-indicator-added ((,class :foreground ,green))) ; OR ,blue for deuteranopia `(diff-indicator-changed ((,class :foreground ,yellow))) `(diff-indicator-removed ((,class :foreground ,red))) `(magit-diff-added ((,class :background unspecified :foreground ,green-faint))) `(magit-diff-changed ((,class :background unspecified :foreground ,yellow-faint))) `(magit-diff-removed ((,class :background unspecified :foreground ,red-faint))) `(magit-diff-context-highlight ((,class :background ,bg-dim :foreground ,fg-dim)))))) ;; This is so that the changes persist when switching between ;; modus-operandi and modus-vivendi (add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-custom-faces) Removed support for packages ============================ The following are no longer supported by the themes. The reasons vary in each case, though they boil down to (i) the package being obsoleted, or (ii) the package's faces inheriting from base faces that we already support (e.g. font-lock). Each case was carefully considered as part of the comprehensive review of all packages supported by the themes, though chances are that some mistake was made regardless. If you believe a package should not have been removed, please report as much. * ag * apt-sources-list * apt-sources-list * buffer-expose * counsel-org-capture-string * define-word * diredc * disk-usage * easy-kill * flyspell-correct * git-gutter{,fringe}+ * git-lens * git-walktree * highlight-blocks * highlight-defined * highlight-escape-sequences * highlight-symbol * highlight-tail * hyperlist-mode * isl (isearch-light) * minibuffer-line * mu4e-conversation * no-emoji * objed * parrot * phi-search * pkgbuild-mode * rainbow-identifiers * sallet * spell-fu * spray * swoop * vdiff * volatile-highlights Changes to supported faces or face groups ========================================= * Eliminated any possible exaggerations in wgrep faces. Those no longer use coloured backgrounds. Instead they have colour-coded foreground colours as well as a bold weight (they ultimately inherit from the 'bold' face, which is a "hidden" customisation option, as explained in the manual). * Forced Org block delimiters to not extend their background by default (though check 'modus-themes-org-blocks'). That was the intended design all along, but now it needs to be made explicit. See, for example, bug#52587 for Emacs: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52587> * Revised the 'org-sexp-date' face so that it no longer looks like 'org-date'. Dates are clickable buttons: they work like links, so they have an underline by default and are subject to the 'modus-themes-links' user option. Whereas the 'org-sexp-date' is not applied to interactive elements and must thus be visually distinct. This face is used for diary-style entries in Org files. For example: %%(diary-anniversary 2000 12 25) NAME %d%s birthday * Rewrote several Auctex/Tex faces to inherit from base faces where relevant (e.g. 'bold', 'success') as well as from font-lock faces. In the latter case, the end-result makes Auctex/Tex subject to the 'modus-themes-syntax' option. These refinements promote theme-wide consistency without detracting from the established styles. * Improved Git (Magit) commit faces for warnings or errors. This concerns two cases: 1. The summary line exceeds the recommended limit of 50 characters. This now uses a yellow foreground colour which contrasts well with the summary line's new blue hue (blue and yellow are complementary for our purposes, meaning that they have good contrast in hueness). 2. The second line (the one right below the summary) has text that should not be there. This one is coloured in a shade of red, which again contrasts well with blue. Thanks to Damien Cassou for noticing in issue 261 that the previous style of applying tinted backgrounds did not work well when 'hl-line-mode' was enabled ('hl-line-mode' overrides backgrounds and so the warnings/errors where not always obvious): <https://gitlab.com/protesilaos/modus-themes/-/issues/261>. * Added support for the new 'magit-branch-warning' face that we helped upstream define: <https://github.com/magit/magit/issues/4550>. It disambiguates warnings in Magit status buffers from the generic and often inappropriate for such a context 'font-lock-warning-face'. * Simplified all the Apropos faces. They no longer look like buttons or links as that makes the presentation of 'M-x apropos' very busy. Instead, they now only have a foreground colour. * Updated support for org-roam faces by removing old entries and covering new ones. * Replaced old company-mode faces with their new aliases: - company-scrollbar-bg => company-tooltip-scrollbar-thumb - company-scrollbar-fg => company-tooltip-scrollbar-track * Made 'org-column-title' inherit from 'fixed-pitch' when the user option 'modus-themes-mixed-fonts' is non-nil. This is needed to line up columns correctly. Thanks to Björn Lindström for the contribution in merge request 52: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/52>. * Forced the 'org-colview' faces to use the same height, even when headings are scaled (see 'modus-themes-headings'). This ensures that the columns are aligned properly and text fits on the same row. Thanks to Björn Lindström for the contribution in merge request 53: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/53>. * Refrained from applying a bold weight to the Org date selection indicator in the calendar. The use of bold has the potential to create problems with the alignment of dates for certain typefaces that do not have a proper bold variant. Also, there is no need for added emphasis given that we already use a prominent background colour. * Made 'M-x org-table-header-line-mode' or the third-party package 'org-table-sticky-header' use colours that fit better with those of tables. * Removed explicit styling of the 'magit-branch-current' face because its definition checks if the ':box' attribute can be set and if not, it uses ':inverse-video'. Useful for terminal emulators. * Expanded support for the 'mode-line-active' face for Emacs29. The face upstream basically adds proportionately spaced fonts (the 'variable-pitch' face) to the mode line. The themes can already use that if the user option 'modus-themes-variable-pitch-ui' is non-nil. Thanks to Manuel Uberti for the feedback in issue 257: <https://gitlab.com/protesilaos/modus-themes/-/issues/257>. * Implemented some stylistic refinements for ERC and Rcirc to ensure theme-wide consistency (e.g. timestamps are a shade of cyan). * Tweaked adoc-mode faces for stylistic theme-wide consistency. * Refashioned all the git faces of Treemacs so that they are more consistent with other such contexts or uses. The new styles also conform with the 'modus-themes-deuteranopia' option. Miscellaneous ============= * Ended the wanton use of internal functions in places that did not require them. Instead, the themes define faces that evaluate such functions once and pass their results to the relevant entries. Cases include: - Symlink and/or broken link faces in contexts such as Dired, Eshell, Helm, Trashed. - Tabbed interfaces (tab-bar, tab-line, centaur-tabs). - Verbatim markup or that of inline code in Org, Markdown, Asciidoc, etc. - The optional use of 'variable-pitch' for User Interface elements (see 'modus-themes-variable-pitch-ui'). * Refined the dedicated diff background colours of modus-vivendi that are used when the user option 'modus-themes-deuteranopia' is non-nil. The changes improve the distinction between all red and yellow constructs in contexts where they appear together (e.g. smerge-mode). Basically, yellows will look more bright, while reds appear as brown. The corresponding blues are toned down a bit to be consistent with the other colours. Consequently, the standard shades of green for added lines (when 'modus-themes-deuteranopia' is nil) are recalibrated to combine well with all other values. * Made several faces return an 'unspecified' value instead of nil for their unused attributes under certain circumstances. This is to guard against third-party code that unconditionally expects a non-nil value. * Omitted {over,under}line attributes from the mode line when the 'padded' property is added to the 'modus-themes-mode-line' user option. Those are not necessary in that context. Thanks to Illia Ostapyshyn for the contribution in merge request 54: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/54> * Rewrote several internal functions in the interest of consistency and clarity. * Deleted two user options that were long obsolete: (i) 'modus-themes-org-habit' has been superseded by 'modus-themes-org-agenda' since version 1.5.0 of the themes and (ii) 'modus-themes-intense-hl-line' has been replaced by 'modus-themes-hl-line' since version 1.3.0. * Removed parentheses from headings in the manual as they are invalid characters for some version of Texinfo. See Emacs bug#52126: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52126>. * Updated all doc strings so that quoted lists yield valid syntax in Help buffers; syntax that can be directly evaluated (otherwise Emacs prettifies straight quotes as curly ones, which break the code). Thanks to Christian Tietze for bringing this issue to my attention: <https://gitlab.com/protesilaos/modus-themes/-/issues/248#note_753169268>. * Rewrote all sections of the manual to document the current state of the project as pertains to valid user options, explicitly supported face groups, and so on. -
1.7.06f696277 · ·
Modus themes version 1.7.0 By Protesilaos Stavrou <info@protesilaos.com> on 2021-11-18 The present entry records the changes made to the project since the release of version 1.6.0 on 2021-09-29. There have been more than 60 commits since then. Every modification pertaining to colour combinations referenced herein is implemented 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). 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 from Emacs by evaluating this form: (info "(modus-themes) Top") The themes are built into Emacs version 28 (next stable release), and are available on GNU ELPA as well as other archives. This release is the first one that is included with Emacs 29, or else the 'master' branch in emacs.git. Customisation options ===================== + The 'modus-themes-no-mixed-fonts' has been deprecated and replaced by the 'modus-themes-mixed-fonts'. This is a breaking change for users who want to use "mixed fonts": they must set the new variable to non-nil. As the name implies, the new variable changes the meaning of the feature to make it opt-in by default. This is consistent with the principle of least surprise, as users may not know why some fonts look different than others in certain cases. Thanks to Christian Tietze for clarifying the doc string of this new user option in merge request 51: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/51>. For context, "mixed fonts" refers to a design where spacing-sensitive constructs, such as code blocks and Org tables, inherit from the 'fixed-pitch' face to remain monospaced (and properly aligned) at all times. Depending on the user's configurations, the 'fixed-pitch' face may not use the typeface that the user expects. The manual provides information on how to set the desired fonts by editing the 'default', 'fixed-pitch', and 'variable-pitch' faces. + The new 'modus-themes-mode-line-padding' can be used to control the apparent padding of the mode line when the user option 'modus-themes-mode-line' includes the 'padded' property. The padding must be a positive integer (otherwise the code would be needlessly complex to guard against values that make the mode line look awkward, like anything lower than -3 or maybe even -2). Thanks to Guilherme Semente and Manuel Uberti for the feedback in issue 245: <https://gitlab.com/protesilaos/modus-themes/-/issues/245>. Note that the out-of-the-box style of the themes has a padding of 1 (technically a ':line-width' of 1 for the ':box' attribute), whereas the default style of Emacs has it at -1. This is a design choice to avoid an overlap between the outer boundaries of a font's glyphs and the borders of the mode line, when using certain common typefaces at various point sizes. Such an overlap can hinder readability. The manual contains a new Do-It-Yourself (DIY) section with detailed code samples on how to apply a negative value. + The new 'modus-themes-intense-markup' option can be set to non-nil to make constructs such as inline code and verbatim text more colourful. This has a general utility, though its consideration was prompted by a phenomenon reported by Stefan Kangas in issue 238 where the overlay of the 'hl-line-face' overrides the subtle background these constructs use and can thus make them virtually indistinguishable from ordinary text: <https://gitlab.com/protesilaos/modus-themes/-/issues/238>. Such is the standard behaviour of 'hl-line-mode' and there is nothing a theme can (or rather "should") do about it. Thanks to Stefan Kangas for the feedback. + The 'modus-themes-headings' option can now accept and apply an exact font weight such as 'semibold' or 'light'. (The list of available weights is the value of the 'modus-themes--heading-weights' internal variable.) This supersedes the now-deprecated 'no-bold' property: 'no-bold' is henceforth understood as the presence of a 'regular' weight. Recall that this user option is an alist and can be used to target heading levels individually, which further reinforces the utility of this new property. Thanks to Christian Tietze for suggesting this idea in issue 248: <https://gitlab.com/protesilaos/modus-themes/-/issues/248>. And thanks to Daniel Mendler for refining its implementation in commit 54bfd62, which was sent as a patch file (yes, we accept those and I actually prefer them over a web app's UI). + The 'modus-themes-org-agenda' has seen improvements to its 'event' key (this is an alist that has multiple keys). It now accepts a 'varied' property which differentiates between (i) plain timestamp entries and (ii) entries that are generated from either the diary or a symbolic expression. The 'varied' property combines with the other available properties to particularise their effects. Consult the doc string or the manual for the technicalities. Thanks to Gustavo Barros for the detailed commentary in issue 241: <https://gitlab.com/protesilaos/modus-themes/-/issues/241>. + The 'modus-themes-lang-checkers' now accepts a 'faint' property. This has the effect of toning down the colours in use. By default, the only colour is that of the underline, though more can be added by combining the properties accepted by this user option. Consult its doc string or the manual for further details. Thanks to Morgan Smith for suggesting the idea in issue 239: <https://gitlab.com/protesilaos/modus-themes/-/issues/239>. Add support for new packages or face groups =========================================== + 'company-tooltip-deprecated' face. Thanks to Roman Rudakov for the feedback in issue 247: <https://gitlab.com/protesilaos/modus-themes/-/issues/247>. + 'corfu-default' face. Thanks to Daniel Mendler (Corfu's developer) for the feedback in issue 254: <https://gitlab.com/protesilaos/modus-themes/-/issues/254>. + 'image-dired' package (Emacs 29). Thanks to Stefan Kangas for making it happen in emacs.git and for the feedback in issue 250: <https://gitlab.com/protesilaos/modus-themes/-/issues/250>. + 'nano-modeline' package. + 'vertico-quick' package. Thanks to Nicolas De Jaeghere for the contribution in merge request 48: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/51>. Changes to existing faces or face groups ======================================== + Added support for the new Org agenda faces that improve the contextuality of various views. We implemented those upstream for Org version 9.5 in close cooperation with Gustavo Barros. Thanks to Gustavo for the detailed feedback in issue 241: <https://gitlab.com/protesilaos/modus-themes/-/issues/241>. The thread about the patch upstream: <https://list.orgmode.org/87lf7q7gpq.fsf@protesilaos.com/> + Refined Org agenda date faces in the interest of consistency and in accordance with the aforementioned change. Thanks again to Gustavo Barros for the discussion in issue 241. + Applied the 'shadow' face more consistently across all contexts where only a subtle foreground value is expected. This design choice makes it possible for users to manually edit the foreground colour of 'shadow' to something even more subtle than the 'fg-alt' palette variable we use, which maps to a gray colour (e.g. they could use "gray50"). + Implemented a subtle background colour to the 'widget-inactive' face. This makes it easier to discern inactive buttons, checkboxes, and the like, in contexts such as the Customize User Interface. Thanks to Stefan Kangas for the feedback in issue 242: <https://gitlab.com/protesilaos/modus-themes/-/issues/242>. + Tweaked 'file-name-shadow' to also use italics (inherit from the 'italic' face) in order to be more easy to distinguish it from ordinary text in the minibuffer. Recall that the manual documents the meaning of inheriting from the 'bold' and 'italic' faces instead of hardcoding a bold weight and an italic slant, respectively. In short: users can change the weight to what they want (e.g. semibold) and/or use distinct font families. + Amplified the style of Version Control (VC) warnings and errors to let them draw more attention to themselves (because these indicators need to be acted upon). + Recoloured the 'custom-group-tag' face to make it fit better in its context and be consistent with the rest of the themes' established patterns. + Made marks for selection in Dired, Ibuffer, and related, conform with the 'modus-themes-success-deuteranopia' option. This means that they use blue colours when the option is non-nil, instead of their default shades of green. + Adjusted the box width of key bindings for Emacs 28 or higher. They should no longer cause any alignment issues. This style is now used throughout the themes, including in transient views (e.g. Magit) which were the exception before. Thanks to Manuel Uberti and Kevin Fleming for the feedback in issue 232: <https://gitlab.com/protesilaos/modus-themes/-/issues/232>. Miscellaneous ============= + Wrote a brief description of every user option in the manual. Also covered its type, as in boolean, alist, et cetera. + Corrected the mode line border width for one combination of properties in the 'modus-themes-mode-line' option. This should now have the same height as all others: (setq modus-themes-mode-line '(accented borderless)) + Ensured that mode line attributes would not be set to nil, but kept at an 'unspecified' value instead, where relevant. This avoids problems with [faulty] code that unconditionally depends on something that does not exist, as in the following while ':box' is nil: (face-attribute 'mode-line :box) + Expanded, reworded, or otherwise improved the manual, based on the aforementioned. Thanks once again to everyone involved! -
1.6.08dbfe43f · ·
Modus themes version 1.6.0 By Protesilaos Stavrou <info@protesilaos.com> on 2021-07-15 This entry records the changes made to the project since the release of version 1.5.0 on 2021-07-15. There have been around 70 commits since then. Every colour-related modification referenced herein is always implemented 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). Such edits also account for colour-coding that is optimised for the needs of users with red-green colour deficiency (deuteranopia or variants). Here is the URL of the manual: <https://protesilaos.com/modus-themes>. Or read it from Emacs by evaluating this form: (info "(modus-themes) Top") The themes are built into Emacs version 28 (current development target), and are available on GNU ELPA as well as other archives. This release is the final one for the emacs-28 branch, as that gets cut as the next stable release of GNU Emacs. Future releases will target Emacs 29 once that becomes the new 'master' branch. Customisation options ===================== [ Themes need to be reloaded for changes to take effect. ] + Introduced the new 'modus-themes-tabs-accented' boolean option. When set to non-nil, it renders the background of all tab interfaces in a shade of blue. Those interfaces are tab-bar (built-in), tab-line (built-in), and Centaur tabs. - The background "accented" colour is the same as the one used for mode lines when 'modus-themes-mode-line' is configured accordingly. + Tweaked the 'modus-themes-mode-line' to accept a 'padded' symbol as part of the list of properties it can read. This will increase the spacing around the mode lines' text, making the line taller overall but also more spacious. Thanks to Manuel Uberti for making the proposal and providing feedback in issue 228: <https://gitlab.com/protesilaos/modus-themes/-/issues/228>. + Added the 'modus-themes-scale-small' which complements the existing scale values with one that is meant to be smaller than the base height. This option is reserved for special cases and is currently only used as an opt-in feature in the Org agenda. + Expanded the 'modus-themes-org-agenda' with more parameters: - The current date can now also be underlined. - Date headings can be scaled/enlarged in size. - Events, like those of the Diary or sexp entries, can be customised. Consult the manual or the variable's doc string for the details. + Removed the obsoleted aliases 'modus-themes-slanted-constructs' and 'modus-themes-scale-5'. Those are superseded by the more appropriately named 'modus-themes-italic-constructs' and 'modus-themes-scale-title'. Thanks to Nicolas De Jaeghere for the patch in merge request 47: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/47>. Faces and face groups ===================== + Make the 'prodigy' faces for red/green/yellow inherit from the faces 'error'/'success'/'warning', respectively. This is done to (i) avoid duplication and (ii) ensure that the green/success colour coding is consistent with the goal of the themes to empower users with red-green colour deficiency. The boolean option that changes all such greens to shades of blue is 'modus-themes-success-deuteranopia'. + Assigned the ':extend' attribute to the 'org-code' face. This is necessary when the Org source contains lines that start with a colon sign. Those are interpreted as code blocks. For example: : #+BEGIN_SRC emacs-lisp : (defun in-interval (bounds el) : (and (>= el (car bounds)) (<= el (cadr bounds)))) : #+END_SRC With the ':extend' in place, the background stretches to the edge of the window, thus giving those lines a uniform rectangular shape. For inline uses of 'org-code', the background should remain limited to the span of the text. + Broadened support for 'marginalia' faces in two phases. - The first pertained to the file permissions that are shown when completing against file paths. Their style is similar to what 'dired+' or the 'direfl' packages provide, however we have taken care to optimise the interface for the purposes of completion UIs---where things can look like Dired, we make them alike, but where they must differ, we differentiate the designs accordingly. There can be no compromises or arbitrary constraints. Also read: <https://github.com/minad/marginalia/pull/91>. - The second batch covered all sorts of extra classes that provide granular control over the appearance of Marginalia instances. Refinements also had to be made to already-supported faces for the sake of achieving consistency across the various Marginalia interfaces. Also read: <https://github.com/minad/marginalia/pull/92>. + Refined 'diredfl' and 'dired+' faces. For the various "priv" faces, the intent is to increase the difference in hueness between adjacent file permissions (the changes are minor, but they do change the overall result). Numbers are toned down so that they do not clash with dates. The file suffix no longer uses cyan to stand out more in detailed views. + Made 'icomplete-selected-match' (Emacs28) more legible by aligning its presentation with metaphors that are estaslished across the modus-themes. Thanks to Kévin Le Gouguec (peniblec) for noting the inconsistency with the new face upstream and for writing the patch for it in merge request 50: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/50>. Also thanks to Manuel Uberti for confirming that things would look consistent in the comments' section of that merge request. + Fixed faulty inheritance for the 'web-mode-keyword-face'. It should now properly copy the attributes of 'font-lock-keyword-face'. + Made inheritance of the new 'help-key-binding' (Emacs28 key) the default for all faces that need to style key bindings. In Emacs 28 all key bindings are automatically displayed with the face 'help-key-binding' which uses some new face attributes to draw a cleaner box around it. Given that the themes must work with earlier versions of Emacs, we cannot inherit it unconditionally so we added the relevant conditionality. It is nice to offer this feature to those who use the themes on Emacs 28. Older versions retain the previous style of a blue colour coupled with a bold weight. The exception to this rule is the transient.el faces (this is the pop-up window used by Magit, among others---transient.el is now built into Emacs). The box effect creates unpredictable misalignments, so we default to the old key binding style for those. Thanks to Manuel Uberti and Kevin Fleming for their feedback in issue 232: <https://gitlab.com/protesilaos/modus-themes/-/issues/232>. + Added support for the new 'notmuch-jump-key' face. I contributed this face in commits c37c9912, 5cc106b0 to the Notmuch git repo: <https://git.notmuchmail.org/git/notmuch>. + Updated the 'bookmark-face' (Emacs28) as it has been changed upstream to be a fringe indicator instead of an in-buffer, line-wide background highlight. + Aligned Ediff faces with other 'modus-themes-diffs' styles. Before we would differentiate a "focus state", though that is now considered surplus to requirements. The notion of a "focus state" only make sense in Magit which applies variegated colour-coding to diff hunks based on their state. Whereas non-active Ediff changes are grayed out, so there is no need for further colour-coding nuances. The most noticeable change is with: (setq modus-themes-diffs 'bg-only) As noted in the commit message of 64c74ae (from 2021-09-04): If users think this change is for the worse, we can always define a helper function like this: (defun modus-themes--ediff-style (bgonly default) "Diff style for Ediff. BGONLY and DEFAULT depend on the value of `modus-themes-diffs'. The former is more subtle." (if (eq modus-themes-diffs 'bg-only) (list bgonly) (list default))) And apply it thus: `(ediff-current-diff-A ((,class :inherit ,@(modus-themes--ediff-style 'modus-themes-diff-removed 'modus-themes-diff-focus-removed)))) No feedback was received towards that end in about a month, so we consider the change to be acceptable, without prejudice to the possibility of future updates. + Unified the styles of 'org-agenda-calendar-sexp', 'org-agenda-diary', and 'org-agenda-calendar-event'. This is not a user-facing change but an internal refactoring to avoid repetition. It also makes things easier for the implementation of the 'modus-themes-org-agenda' (as mentioned above). + Ensured that the 'bookmark-menu-bookmark' face inherits from the 'bold' face. By default it hardcodes the bold weight, whereas we instruct it to inherit the 'bold' face. A user can thus change the ':weight' of that face to whatever they want, like semibold, extrabold, etc. We do this throughout the themes for bold and italics---consider it a "hidden feature" of sorts. Check the manual for more on the matter: (info "(modus-themes) Configure bold and italic faces (DIY)") + Provided support for tab-bar groups (Emacs28). Specifically the faces 'tab-bar-tab-group-current' and 'tab-bar-tab-group-inactive'. Thanks to Adam Porter (alphapapa) for the feedback in issue 8 over at the Github mirror: <https://github.com/protesilaos/modus-themes/issues/8>. + Decoupled the 'stripes' face from that of 'hl-line-face'. This is because the stripes are not meant to change depending on the value of the user option 'modus-themes-hl-line'. + Revised the red shade of "flagged" entries in mu4e and notmuch. Those are now consistent with Gnus. The shade of red that was used before was closer to the orange side of the spectrum whereas the current has hints of blue (a cherry colour) and thus combines better with the cyan and blue that prevail in those interfaces. These are fine margins, though the effect is noticeable regardless. + Configured the new 'ansi-color' faces (Emacs28) which are used by shells and terminals (among others). Thanks to Manuel Uberti for reporting the changes to upstream Emacs in issue 236: <https://gitlab.com/protesilaos/modus-themes/-/issues/236>. + Expanded support for EMMS faces, pertaining to its browser views. Thanks to Feng Shu (tumashu) for bringing those to my attention in issue 11 over at the Github mirror: <https://github.com/protesilaos/modus-themes/issues/11>. + Styled the new 'tab-line-tab-modified' face (Emacs28). It should now use a faint red colour to denote changes to the underlying file. Thanks to Adam Porter (alphapapa) for bringing it to my attention in issue 12 over at the Github mirror: <https://github.com/protesilaos/modus-themes/issues/12>. + Configured the single face that the 'cursor-flash' package has to offer. Thanks to Manuel Uberti for the feedback in issue 231: <https://gitlab.com/protesilaos/modus-themes/-/issues/231>. + Included 'elpher' in the list of supported packages by means of covering the heading faces it implements. + Recalibrated certain dedicated colours for inactive tabs and tweaked tab faces to (i) marginally improve the default aesthetic and (ii) harmonise it with the style of 'modus-themes-tabs-accented'. + Removed the foreground attribute from all markup faces that are meant to denote emphasis in italics. That is because such faces are typically composed with others, so we do not wish to inadvertently override any other colour that would otherwise have taken effect. + Wrote the faces for upstream Org that improve the contextuality of various agenda views (included in version 9.5). This was done in close collaboration with Gustavo Barros who offered detailed feedback in issue 208 (which also led to the creation and eventual expansion of the 'modus-themes-org-agenda' user option): <https://gitlab.com/protesilaos/modus-themes/-/issues/208>. Four new faces improve certain styles and offer more flexibility for some Org agenda views: 'org-agenda-date-weekend-today', 'org-imminent-deadline', 'org-agenda-structure-secondary', 'org-agenda-structure-filter'. They inherit from existing faces in order to remain backward-compatible. Quoting from <https://list.orgmode.org/87lf7q7gpq.fsf@protesilaos.com/>: + The 'org-imminent-deadline' is useful to disambiguate generic warnings from deadlines. For example, a warning could be rendered in a yellow colored text and have a bold weight, whereas a deadline might be red and styled with italics. + The 'org-agenda-structure-filter' applies to all tag/term filters in agenda views that search for keywords or patterns. It is designed to inherit from 'org-agenda-structure' in addition to the 'org-warning' face that was present before (and removes the generic 'warning' face from one place). This offers the benefit of consistency, as, say, an increase in font height or a change in font family in 'org-agenda-structure' will propagate to the filter as well. The whole header line thus looks part of a singular design. + The 'org-agenda-structure-secondary' complements the above for those same views where a description follows the header. For instance, the tags view provides information to "Press N r" to filter by a numbered tag. Themes/users may prefer to disambiguate this line from the header above it, such as by using a less intense color or by reducing its height relative to the 'org-agenda-structure'. + The 'org-agenda-date-weekend-today' provides the option to differentiate the current date on a weekend from the current date on weekdays. Other patches I have made to, inter alia, emacs.git and org.git with regard to faces are documented in previous change log entries. Documentation ============= + Removed references to old versions of the themes from before their refactoring in version 1.0.0. Those old packages no longer exist. Users must install the 'modus-themes' and then load either of 'modus-operandi' or 'modus-vivendi'. + Included various extensions of the Vertico package in the list of indirectly supported packages. Those define faces which either inherit from basic ones that we already support or use colours that are consistent with our accessibility target. + Referenced 'side-hustle', 'tide', 'bufler' as an indirectly supported packages for the same reasons. + Simplified time-stamp local variables that are used in modus-themes.el to show the time the file was edited. We apply 'time-stamp-pattern' instead of setting multiple time-stamp variables. Thanks to Stephen Gildea for the patch, which was sent to me via email (yes, you can always do that). + Updated the manual's "acknowledgements" section to name all new contributors to code/ideas/feedback. + Furnished information on how to configure the 'highlight-parentheses' package and extend its faces for use with the themes. The entry provides a complete Elisp implementation. + Improved the code samples for the prism.el setup that users may wish to set up by themselves. The new lists of colours work better when Prism's colouration is limited to a small set of hues. + Deleted trailing whitespace in the manual which had adverse effects when trying to compile the modus-themes.org over at emacs.git. Thanks to Philip Kaludercic for the patch in merge request 49: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/49>. Thanks again to everyone involved. Looking forward to see the Modus themes, version 1.6.0, as part of the next stable release of Emacs. -
1.5.0b6fb7cda · ·
Modus themes version 1.5.0 By Protesilaos Stavrou <info@protesilaos.com> on 2021-07-15 This entry outlines the set of changes made to the project since the release of version 1.4.0 on 2021-05-25. There have been over 130 commits since then. Every colour-related modification referenced herein is always implemented 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). Such edits also account for colour-coding that is optimised for the needs of users with red-green colour deficiency (deuteranopia or variants). Here is the URL of the manual: <https://protesilaos.com/modus-themes>. Or read it from Emacs by evaluating this form: (info "(modus-themes) Top") The themes are built into Emacs version 28 (current development target), and are available on GNU ELPA as well as other archives. Customisation options ===================== Overview of new style of sets of properties ------------------------------------------- Several variables now accept a list of symbols as a value. Those represent properties, which can be combined with each other to realise the possible styles. The idea was to simplify their specification in order to make them easier to both maintain and extend. Thanks to Philip Kaludercic for introducing this concept in issue 210: <https://gitlab.com/protesilaos/modus-themes/-/issues/210>. The variables are: + 'modus-themes-prompts' by Philip Kaludercic in merge request 43: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/43> + 'modus-themes-mode-line' by Philip Kaludercic in merge request 40: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/40>. + 'modus-themes-lang-checkers' by Philip Kaludercic in merge request 46: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/46> + 'modus-themes-org-agenda' + 'modus-themes-links' + 'modus-themes-headings' + 'modus-themes-hl-line' + 'modus-themes-paren-match' + 'modus-themes-region' + 'modus-themes-syntax' Take 'modus-themes-syntax' as an example. Up until version 1.4.0, it would only accept a symbol, signifying a predefined style. So we had the possible value 'faint' and another 'faint-yellow-comments'. To make a third variant of the "faint" aesthetic, such as by combining it with the "alt syntax" and/or "green strings", we would need to write new presets in the form of 'faint-green-strings', 'faint-alt-syntax', 'faint-alt-syntax-green-strings', 'faint-green-strings-yellow-comments', 'faint-alt-syntax-green-strings-yellow-comments'. That would have been inefficient, hence why it was not done. With the new approach of defining a list of properties, those combinations are all possible. Such as: (setq modus-themes-syntax '(faint alt-syntax)) (setq modus-themes-syntax '(yellow-comments alt-syntax green-strings)) The order in which the properties are set is not significant. The doc string of each of the aforementioned variables, or the corresponding entry in the manual, provides guidance on how to configure things. The old forms will continue to work for the time being, though they are considered deprecated and will stop being supported at a future date. Changes in stylistic variants for variables with sets of properties ------------------------------------------------------------------- + The meaning of the "alt syntax" style in 'modus-themes-syntax' has been redefined. In the past, it used to have green-coloured strings and doc strings. Those are now red. Some other changes have been implemented to make the overall looks more consistent. Users who liked the old style can retain it by passing this list of properties: (alt-syntax green-strings) New styles for the "faint" aesthetic are possible, here shown as lists of properties: (faint green-strings) (faint alt-syntax) (faint alt-syntax green-strings) To each of those the 'yellow-comments' property can be added as well. Consult the doc string or the manual for the technicalities and code samples. + The 'modus-themes-hl-line' no longer has styles that include only an underline. Those proved to be problematic under certain circumstances and were thus removed. Minor changes have been implemented to make the following combination of properties more consistent, by colourising the underline: (accented intense underline) + The 'modus-themes-paren-match' now has styles that include an 'underline' property. Those extend the old options, such as: (bold intense underline) + The 'modus-themes-headings' have an improved set of styles for the "no text color" aesthetic. Those involve the 'monochrome' property, which can now yield results that include a background (whereas before it was just colourless text for the headings, optionally without a bold weight). As this is an alist, here is an example (always check the docs for fully fledged code samples): (setq modus-themes-headings '((1 . (background overline)) (2 . (overline background rainbow)) (t . (monochrome no-bold background)))) To allow a heading level N to retain its original style, a 't' value can be passed. In the previous version of the themes, it was possible to use 'nil' for the same purpose, though that is no longer valid. In those cases, the fallback value of the alist will be used instead, such as what is noted above: (t . (monochrome no-bold background)) + The 'modus-themes-links' provide several new possible styles, due to an expanded set of properties that includes, among others, 'bold', 'italic', and 'background'. The documentation covers the details. + The 'modus-themes-lang-checkers' can now attain a style that uses a prominently coloured background in addition to what was available before as a subtle background and the other variants. New variables ------------- + The 'modus-themes-org-agenda' provides the means to refashion the entirety of the Org agenda buffer. The value it accepts is an alist, with some keys expecting a symbol and others a list of properties. The minutia are covered in its doc string. A possible configuration can look like this: (setq modus-themes-org-agenda '((header-block . (variable-pitch scale-title)) (header-date . (grayscale workaholic bold-today)) (scheduled . uniform) (habit . traffic-light))) 'modus-themes-org-agenda' supersedes the old variable that was specific to the Org habit graph: 'modus-themes-org-habit'. There now is a 'habit' key which accepts the same values as before, plus a new style that is optimised for users with red-green colour deficiency: 'traffic-light-deuteranopia'. Please consult the doc string of 'modus-themes-org-agenda' or the relevant entry to the manual. Thanks to Gustavo Barros for contributing to the creation of this variable as well as to all other changes in the relevant faces that were done in the interest of usability. A full report about 'modus-themes-org-agenda' with screen shots is available here: <https://protesilaos.com/codelog/2021-06-02-modus-themes-org-agenda/>. A patch has been sent to upstream Org, with its review pending, which improves upon some of the areas we had identified: <https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00092.html>. + The 'modus-themes-inhibit-reload' controls a new behaviour of automatically reloading the active theme when an option is set via the Custom interfaces or with 'customize-set-variable'. To opt-in to this feature, set the variable to a 'nil' value. Thanks to Philip Kaludercic for implementing this in merge request 40: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/40>. In the development phase of this option, a bug was identified pertaining to recursion, as reported by Gustavo Barros in issue 213: <https://gitlab.com/protesilaos/modus-themes/-/issues/213>. Changes have been made to remove that possibility, as found in merge request 45: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/45>. A thread was started on the emacs-devel mailing list to inquire upon the technicalities of this option, but it did not gain any traction: <https://lists.gnu.org/archive/html/emacs-devel/2021-06/msg00828.html>. As such, we have decided to take our chances by pressing on with this feature. Users who are interested in it are encouraged to give it a try and report any possible complications. Issue 213 remains open. + The 'modus-themes-italic-constructs' is the new name of the variable 'modus-themes-slanted-constructs'. The term "slant" was considered too vague or technical and some users could have missed the meaning of this option. + The 'modus-themes-scale-5' is renamed to 'modus-themes-scale-title' to better convey its utility. Changes to the manual ===================== + Rewrote or introduced the documentation for all the customisation options mentioned above. Also updated relevant code samples, such as in the manual's introduction to the customisation options. Evaluate this form for an annotated code overview: (info "(modus-themes) Customization Options") + Rephrased a reference to "gamma ray values" as "gamma values". Thanks to Anders Johansson for the contribution in merge request 42: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/42>. + Removed the Org macro that would insert the build date in the manual's introduction. This was required to make the file reproducible, otherwise it would keep changing each time a new version of Emacs was built. Refer to Emacs bug#48661 by Glenn Morris: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48661>. + Included note on tweaking the key hints that the Avy package produces. This is in response to issue 215 by Rudolf Adamkovič: <https://gitlab.com/protesilaos/modus-themes/-/issues/215>. Thanks to Nicolas De Jaeghere for providing the text. + Wrote a note on how to control the underlines that are generated in compilation-mode buffers and related. It is about configuring the variable 'compilation-message-face'. + Documented how to configure the colours that are applied to the names of the days in the 'M-x calendar' interface. The relevant variable is 'calendar-weekend-days'. + Elaborated on a "do it yourself" (DIY) guide on how to benefit from the hidden feature of the themes about how they handle the bold weight and the italic slant. In short, we do not hardcode values and thus make it easy for users to specify the particularities of what it means for a face to have a 'bold' or 'italic' attribute. Faces and face groups ===================== New entries ----------- Newly supported packages: + 'ledger-mode'. Thanks to Pengji Zhang for the feedback in issue 202: <https://gitlab.com/protesilaos/modus-themes/-/issues/202>. + 'gotest'. Thanks to Jerry Zhang for the feedback in issue 226: <https://gitlab.com/protesilaos/modus-themes/-/issues/226>. + 'css-mode' New faces for already supported groups: + 'shr-h1', 'shr-h2', 'shr-h3', 'shr-h4', 'shr-h5', 'shr-h6' of the shr.el library (simple HTML renderer, as experienced in, for example, EWW). Those are available for Emacs28, with a patch by me: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=49433> + 'apropos-button' as a generic face that fontifies faces in apropos buffers. Available for Emacs28, with a patch by me: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49162>. + 'selectrum-mouse-highlight'. This makes the mouse hover effect for selectrum look the same as in most other contexts. Thanks to okamsn for the feedback in issue 203: <https://gitlab.com/protesilaos/modus-themes/-/issues/203>. Review of existing entries -------------------------- + Added an ':extend' property to 'next-error' face. This face is used for pulse effects. It is good to have them extend to the edge of the window, so that they are easier to spot. Thanks to Gustavo Barros for the feedback in issue 200, which is about pulse.el: <https://gitlab.com/protesilaos/modus-themes/-/issues/200>. + Tweaked the various Apropos faces. The idea was to remove the colour from the pseudo headings so that we would not get an exaggerated result of too much variety in the buffer (e.g. that of 'M-x apropos'). The individual buttons retain their style as links, meaning that they are governed by the variable 'modus-themes-links'. + Revised 'whitespace-line' face to make it look like a warning, as it ought to be. Thanks to Pengji Zhang for the feedback in issue 204: <https://gitlab.com/protesilaos/modus-themes/-/issues/204>. + Reworked the colour-coding of the Hydra and Transient packages. These are meant to tone down some excesses with the standard red and to adapt other colours to it. Thanks to Gustavo Barros for providing suggestions and helping me tweak those in issue 206: <https://gitlab.com/protesilaos/modus-themes/-/issues/206>. + Recoloured 'transient-argument' to improve its uniqueness in its context and to better comply with the expectation of hydra-style colour coding, as noted right above. + Made the 'org-agenda-done' face conform with the customisation option 'modus-themes-success-deuteranopia'. This means that it will be coloured in blue instead of green when the option is set to a non-nil value. + Grayed out the foreground of the Org block delimiter lines on the premise that any extra colouration was not needed, given the presence of a gray background and the overall markup of the block. + Toned down the colouration of the 'org-code' face, so that it is consistent with 'org-verbatim' as well as the colours used in opening and closing lines of blocks. Thanks to Gustavo Barros for suggesting this change in issue 206, though it went through a couple of reviews: <https://gitlab.com/protesilaos/modus-themes/-/issues/206>. + Simplified the inheritance of the 'fixed-pitch' face, which is used for internal purposes to ensure alignment of elements in buffers that must cope with mixed font configurations, such as an org-mode file with 'M-x variable-pitch-font' enabled. [ Recall that the option 'modus-themes-no-mixed-fonts' can disable this feature. Also note that the 'mixed-fonts' package, or equivalent, is not needed while using the Modus themes (though there is nothing wrong with having them together). ] + Reduced the overall intensity of 'org-mode-line-clock-overrun'. Thanks to Gustavo Barros for the feedback in issue 208: <https://gitlab.com/protesilaos/modus-themes/-/issues/208>. + Simplified or otherwise tweaked several Org agenda faces to render possible the new 'modus-themes-org-agenda' variable, as documented above. Thanks to Gustavo Barros for the feedback in issue 208: <https://gitlab.com/protesilaos/modus-themes/-/issues/208>. + Increased ever so slightly the foreground colour of the 'highlight' face. This can help improve the perception of highlights, such as upon hovering over a link with the mouse. Thanks to Rudolf Adamkovič for reporting the potential problem in issue 216: <https://gitlab.com/protesilaos/modus-themes/-/issues/216>. + Prevented the override of the 'diff-context' face when users assign a 'bg-only' value to the 'modus-themes-diffs' variable. This makes it consistent with the intent of this style, which is to work with a non-nil value for 'diff-font-lock-syntax' (basically to allow the usual colour highlights of the underlying code syntax in diff buffers). + Ensured consistency of all prompt-related faces by introducing a new face, 'modus-themes-prompt', that is inherited by all others (all prompt styles are controlled by the variable 'modus-themes-prompts'). This was originally implemented with the 'comint-highlight-prompt' face, though that could potentially lead to undefined faces if the comint library was not loaded. Whereas the 'modus-themes-prompt' guarantees that we pass a known face at all times. Thanks to Philip Kaludercic for bringing this potential bug to my attention in a comment to merge request 43: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/43#note_615224855>. + Removed the background colour from the 'widget-inactive' face. It would create problems in some cases, such as in Custom buffers for multiple choice options. + Refined 'calendar-weekend-header' and 'calendar-weekday-header' to emulate the design of physical calendars and remain truthful to the expectations set by the default configuration of the calendar.el library. Weekends now use a faint red, while weekdays are rendered in the same subtle gray they had before. The underlying principle is to make weekends convey a subtle warning to the effect that "this is not a day for work" (notwithstanding precarious economic realities). As noted above, there is an entry in the manual on how to make all days look the same, be it gray or faint red. Evaluate this form: (info "(modus-themes) Note on calendarel weekday and weekend colors") Request for feedback on a potential version 2.0.0 of the Modus themes ===================================================================== While we maintain a cautious stance towards preserving the default styles, there are some cases where we might be forced to introduce backward-incompatible changes. Three such cases that can benefit from user feedback are: + Issue 196 on 'modus-themes-no-mixed-fonts' <https://gitlab.com/protesilaos/modus-themes/-/issues/196>. + Issue 198 on 'modus-themes-hl-line' <https://gitlab.com/protesilaos/modus-themes/-/issues/198> [ Note that 'modus-themes-hl-line now accepts a list of properties as described in the opening sections of this entry. ] + Issue 218 on 'modus-themes-diffs' <https://gitlab.com/protesilaos/modus-themes/-/issues/218>. Miscellaneous ============= + Recalibrated the value of the colour 'bg-hl-line-intense' in the palette 'modus-themes-vivendi-colors'. The change should be practically indecipherable, though it slightly improves things in certain contexts. + Refined the intensity of the three main yellow colours in 'modus-themes-vivendi-colors'. + Introduced a new 'modus-themes-faces' group so that those are decoupled from the customisation options in the various Custom buffers. Thanks to Philip Kaludercic for the patch in merge request 39: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/39>. + Updated the manual's "Acknowledgements" section to include all new users who contributed to the project. Thanks again to everyone involved! -
1.4.015c973f7 · ·
Modus themes version 1.4.0 By Protesilaos Stavrou <info@protesilaos.com> on 2021-05-25 This entry records the changes made to the project since the release of version 1.3.0 on 2021-04-17. There have been around 100 commits in the meantime, as is the norm. If you are coming from older versions, please consult the change log entry for version 1.0.0 with regard to the breaking changes that were introduced. Every colour-related modification is always done in accordance with the overarching 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). URL of the official manual: <https://protesilaos.com/modus-themes>. Or read it with Emacs' Info reader by evaluating this form: (info "(modus-themes) Top") Remember that the themes are built into Emacs version 28 (current development target), and are available on GNU ELPA, as well as other archives. Customisations variables ------------------------ + Redefined the style of 'fg-only' that 'modus-themes-diffs' accepts, so that it no longer uses a red-green colour coding, but applies a red-blue distinction instead. The symbol 'fg-only' is a deprecated alias for the more descriptive 'fg-only-deuteranopia'. This is done because green text on a light background is one of the worst combinations for the purposes of legibility, as it does not stand out in its context and thus forces undesirable compromises. Whereas red and blue work well in this case, while making the style accessible to users with red-green colour deficiency (deuteranopia). To avoid inconsistencies between Modus Operandi and Modus Vivendi, we replace green with blue in both themes. A full report is available in issue 183 which was created on April 21, 2021: <https://gitlab.com/protesilaos/modus-themes/-/issues/183>. + Introduced the boolean 'modus-themes-success-deuteranopia' which replaces all instances of green with blue in contexts where a red-green colour coding is in effect (e.g. Org TODO vs DONE keywords, isearch current match...). + Implemented 'modus-themes-mail-citations' to control the colouration of cited text in email-related buffers, such as Gnus or message.el. It accepts values nil, 'faint', and 'monochrome'. By default (the nil value) the text of citations cycles through blue, green, red, yellow depending on the level of depth. + Expanded the set of options for 'modus-themes-mode-line' to encompass the values 'borderless-accented', 'borderless-accented-3d', and 'borderless-accented-moody'. Those are variations of existing styles. The complete list: - nil (default) - 3d - moody - borderless - borderless-3d - borderless-moody - accented - accented-3d - accented-moody - borderless-accented - borderless-accented-3d - borderless-accented-moody + Renamed the non-nil values that 'modus-themes-org-blocks' accepts from 'grayscale', 'rainbow' to 'gray-background' and 'tinted-background', respectively. The new symbols better describe their effect on Org source blocks, namely, that they affect the background of the block rather than the foreground. The old symbols will still work but are considered deprecated aliases of the newer ones. + Altered the intensity of the 'modus-themes-hl-line' option 'accented-background' to a more noticeable shade of cyan/teal. The old style was too subtle to have the desired effect. The value 'underline-accented' is not affected by this change, as it still uses the same subtle background it did before in combination with a more pronounced underline colour. + Deleted all deprecation warnings that concerned the transition from version 0.13.0 of the themes to 1.0.0. Those had been in effect for several months, spanning four tagged releases. Faces or face groups -------------------- + Reconsidered the use of colour in all email-related citation faces to avoid exaggerations and reduce complexity. Colour values have been tweaked to tone down their overall intensity, while the number of colours has been reduced to four. Gnus and Mu4e have faces for more levels of citation depth, though those will simply repeat the four-colour cycle. + Made the 'message-mml' face look consistent with the rest of the buffer while composing an email by changing its foreground colour from a yellow to a cyan variant. + Refined several faces in the Notmuch group in the interest of harmony: - Individual message headers in 'notmuch-show-mode' use bold text in addition to their existing subtle background to better stand out in their context. The face is 'notmuch-message-summary-face'. - Tags are no longer set unconditionally to a bold typographic weight. They become such for unread threads in 'notmuch-search-mode' buffers, as well as for headers of 'notmuch-show-mode'. - Removal and addition of tags is now denoted by a strike-through and an underline effect, respectively, whereas before they both used underlines with the only difference being their colour. - The subject line in 'notmuch-search-mode' buffers uses the main foreground instead of a dimmed one. The field of matching authors has a tweaked foreground to keep the tabular view easy to read. - All cryptography-related faces are simplified to not show a coloured background but only use a foreground colour instead. + Removed direct support for 'counsel-notmuch' as it already inherits from the relevant notmuch faces. The package is thus considered indirectly supported. + Refrained from setting a background to the 'csv-separator-face' as it would inevitably colourise the negative space in the tabular view created by 'csv-align-mode'. A red text colour is used instead, even though this is not common practice: it is easier to spot for small, single characters, such as a comma or a semicolon that is meant to have a special meaning. Thanks to Kevin Fleming for reporting the problem and for offering feedback on the choice of colour in issue 194: <https://gitlab.com/protesilaos/modus-themes/-/issues/194>. + Distinguished between ordinary links and widget buttons by removing the underline from the latter (the 'widget-button' face) and altering the shade of its foreground colour. Such widgets are used in Emacs' Custom interfaces and can also be found in the default Notmuch "hello" buffer that runs 'notmuch-hello-mode'. + Tweaked the Ediff current faces to be consistent with 'diff-mode' and related. In practice, this only applies when 'modus-themes-diffs' is set to a value of 'fg-only-deuteranopia', as it adds a dim background to the current diff hunk. All other styles of 'modus-themes-diffs' look the same as before while using Ediff. + Simplified the faces of 'corfu' to match the current state of the upstream project. Thanks to Daniel Mendler (its developer) for reporting this in issue 184: <https://gitlab.com/protesilaos/modus-themes/-/issues/184>. + Refined all Eshell faces so that the output of 'ls' is consistent with the overall aesthetic of the themes. Also made 'eshell-prompt' inherit from 'comint-highlight-prompt' to look the same as other such prompts (all are configurable by 'modus-themes-prompts'). + Revised 'eshell-prompt-extras' and 'eshell-git-prompt' to use colours and typographic weight that better match the style of the various configurations they offer. + Simplified 'eshell-syntax-highlighting' to inherit from the standard Eshell faces, where appropriate. + Adjusted the colour of 'centaur-tabs-active-bar-face' and removed the bespoke 'fg-tab-accent' colour from 'modus-themes-operandi-colors' and 'modus-themes-vivendi-colors' that was only used by it (and which should have never been introduced to begin with). + Updated the 'tab-bar-groups' faces to match changes upstream. Thanks to Fritz Grabo (its developer) for the patch in merge request 35: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/35>. + Changed the Ibuffer title and group faces to better differentiate between group titles and special or non-file-visiting buffers. Thanks to Nicolas De Jaeghere for the patch in merge request 37: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/37>. + Ensured that all faces that denote a "success" state, or which are expected to be coloured in green in a red-green binary, can use an appropriate blue colour (or colour combination that involves blue) instead when 'modus-themes-success-deuteranopia' is set to a non-nil value. + Added support for the new 'bookmark-face' in Emacs version 28. This means that the built-in bookmark.el library is directly supported by the themes. This face can be disabled by setting 'bookmark-fontify' to nil. Thanks to Mark Barton for reporting the presence of this new face and for providing feedback on its style in issue 189: <https://gitlab.com/protesilaos/modus-themes/-/issues/189>. + Aligned 'hes-mode' ('highlight-escape-sequences') with the standard font-lock faces for regexp grouping. This means that it conforms with changes to the 'modus-themes-syntax' variable. + Reconfigured the 'org-quote' face to adapt its style depending on the value of 'modus-themes-org-blocks'. The default is a subtle blue/cold foreground colour against the main background. When a value of 'gray-background' is assigned to 'modus-themes-org-blocks', the text's colour becomes that of the main foreground in order to maintain a good level of legibility. Thanks to Rudolf Adamkovič for the feedback in issue 190: <https://gitlab.com/protesilaos/modus-themes/-/issues/190>. + Refashioned the 'show-paren-match-expression' face to make it apply a bespoke background colour and not override the expression's foreground colours. This face is used by 'show-paren-mode' when the customisation variable 'show-paren-style' is set to the 'expression' value. Thanks to Rudolf Adamkovič for the feedback in issue 191: <https://gitlab.com/protesilaos/modus-themes/-/issues/191>. + Made headings level 8 use a fine shade of magenta by default instead of gray (notwithstanding user changes to 'modus-themes-headings'). This should have a negligible difference in Org or Outline buffers, but is more noticeable when editing Elisp in Emacs28 while also using 'outline-minor-mode' and with 'outline-minor-mode-highlight' set to 'override'. That is because several top-level forms use that heading level with those configurations. Documentation (the manual) -------------------------- + Incorporated a sample configuration block with all customisation variables and with comment annotations of their available options, in an attempt to make it easier for users to discover what the themes provide. + Replaced all instances of "modeline" with "mode line" for consistency with the Emacs style. Thanks to Rudolf Adamkovič for the patch that started this process in merge request 33: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/33>. + Wrote note on setting mode line faces that indicate the state of 'god-mode'. Thanks to Rudolf Adamkovič for the feedback in issue 187: <https://gitlab.com/protesilaos/modus-themes/-/issues/187>. Also thanks to Rudolf for updating the applicable hook in merge request 34: <https://gitlab.com/protesilaos/modus-themes/-/merge_requests/34>. + Listed 'org-mode' variables that affect fontification in blocks: 'org-src-fontify-natively', 'org-fontify-whole-block-delimiter-line', and 'org-fontify-quote-and-verse-blocks'. This complements the already documented variables 'org-fontify-whole-heading-line' and 'org-fontify-done-headline' that pertain to headings. + Included note on fontifying inline Latex expressions in Org buffers. Thanks to Rudolf Adamkovič for the feedback in issue 190: <https://gitlab.com/protesilaos/modus-themes/-/issues/190>. + Elaborated on the use of 'face-remap-add-relative' by means of sample code that cycles through arbitrary colours for the 'region' face. This is filed under the "Do It Yourself" (DIY) section. + Provided a DIY method for adapting the fontification of Org source block delimiter lines to the value of 'modus-themes-org-blocks'. + Expanded the DIY entry on overriding the saturation of the active theme's colours with a method that combines the programmatic approach with manual overrides. The user can thus specify the colour values they want to override and let the rest be handled by Elisp. + Introduced a section with answers to Frequently Asked Questions (FAQ) about the design of the themes as well as recommendations on how to ensure optimal reading conditions or start thinking about them. The questions are: - Is the contrast ratio about adjacent colors? - What does it mean to avoid exaggerations? - Why are colors mostly variants of blue, magenta, cyan? - What is the best setup for legibility? Miscellaneous ------------- + Removed superfluous code from internal functions and adapted their indentation to make them easier to read. + Recalibrated some values in 'modus-themes-vivendi-colors' to ensure consistency in luminance with other colours that are used in their context. Those are subtle changes that can only be discerned in side-by-side comparisons of the before and after states. Thanks to André Alexandre Gomes for the feedback in issue 193: <https://gitlab.com/protesilaos/modus-themes/-/issues/193>. + Changed the saturation and hueness of the bespoke 'fg-comment-yellow' in 'modus-themes-operandi-colors' and 'modus-themes-vivendi-colors' to better contrast with its context, while still keeping its luminance consistent with its role as a colour for comments in code. This is used when 'modus-themes-syntax' is configured appropriately (read its doc string or consult the manual). + Attempted to add explicit support for the faces of the built-in pulse.el library, but ultimately opted against them as the doc string of 'pulse-highlight-face' advises against customising it, even though it is not clear from the source code in emacs.git what the problem could be. We shall reconsider this case for the next release cycle. Thanks to Gustavo Barros for the feedback on several aspects of this topic in issues 185 and 200: - <https://gitlab.com/protesilaos/modus-themes/-/issues/185> - <https://gitlab.com/protesilaos/modus-themes/-/issues/200> + Took the feedback of John Haman in issue 199 as a reminder to complete the set of possible values for the 'modus-themes-mode-line' variable: <https://gitlab.com/protesilaos/modus-themes/-/issues/199>.