6275 lines
262 KiB
Plaintext
6275 lines
262 KiB
Plaintext
This is modus-themes.info, produced by makeinfo version 7.0.3 from
|
||
modus-themes.texi.
|
||
|
||
Copyright (C) 2020-2023 Free Software Foundation, Inc.
|
||
|
||
Permission is granted to copy, distribute and/or modify this
|
||
document under the terms of the GNU Free Documentation License,
|
||
Version 1.3 or any later version published by the Free Software
|
||
Foundation; with no Invariant Sections, with the Front-Cover Texts
|
||
being “A GNU Manual,” and with the Back-Cover Texts as in (a)
|
||
below. A copy of the license is included in the section entitled
|
||
“GNU Free Documentation License.”
|
||
|
||
(a) The FSF’s Back-Cover Text is: “You have the freedom to copy and
|
||
modify this GNU manual.”
|
||
|
||
INFO-DIR-SECTION Emacs misc features
|
||
START-INFO-DIR-ENTRY
|
||
* Modus Themes: (modus-themes). Elegant, highly legible and customizable themes.
|
||
END-INFO-DIR-ENTRY
|
||
|
||
|
||
File: modus-themes.info, Node: Top, Next: Overview, Up: (dir)
|
||
|
||
Modus themes for GNU Emacs
|
||
**************************
|
||
|
||
Copyright (C) 2020-2023 Free Software Foundation, Inc.
|
||
|
||
Permission is granted to copy, distribute and/or modify this
|
||
document under the terms of the GNU Free Documentation License,
|
||
Version 1.3 or any later version published by the Free Software
|
||
Foundation; with no Invariant Sections, with the Front-Cover Texts
|
||
being “A GNU Manual,” and with the Back-Cover Texts as in (a)
|
||
below. A copy of the license is included in the section entitled
|
||
“GNU Free Documentation License.”
|
||
|
||
(a) The FSF’s Back-Cover Text is: “You have the freedom to copy and
|
||
modify this GNU manual.”
|
||
|
||
This manual, written by Protesilaos Stavrou, describes the
|
||
customization options for the Modus themes, and provides every other
|
||
piece of information pertinent to them.
|
||
|
||
The documentation furnished herein corresponds to stable version
|
||
4.2.0, released on 2023-05-30. Any reference to a newer feature which
|
||
does not yet form part of the latest tagged commit, is explicitly marked
|
||
as such.
|
||
|
||
Current development target is 4.3.0-dev.
|
||
|
||
• Package name (GNU ELPA): ‘modus-themes’
|
||
• Official manual: <https://protesilaos.com/emacs/modus-themes>
|
||
• Change log: <https://protesilaos.com/emacs/modus-themes-changelog>
|
||
• Color palette: <https://protesilaos.com/emacs/modus-themes-colors>
|
||
• Sample pictures:
|
||
<https://protesilaos.com/emacs/modus-themes-pictures>
|
||
• 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>
|
||
• Backronym: My Old Display Unexpectedly Sharpened ... themes
|
||
|
||
* Menu:
|
||
|
||
* Overview::
|
||
* Installation::
|
||
* Enable and load::
|
||
* Customization options::
|
||
* Advanced customization::
|
||
* Face coverage::
|
||
* Notes on individual packages::
|
||
* Frequently Asked Questions::
|
||
* Contributing::
|
||
* Acknowledgements::
|
||
* GNU Free Documentation License::
|
||
* Indices::
|
||
|
||
— The Detailed Node Listing —
|
||
|
||
Overview
|
||
|
||
* How do the themes look like::
|
||
* Learn about the latest changes::
|
||
|
||
Installation
|
||
|
||
* Install manually from source::
|
||
* Install from the archives::
|
||
* Install on GNU/Linux::
|
||
* Dealing with byte compilation errors::
|
||
|
||
Install on GNU/Linux
|
||
|
||
* Debian 11 Bullseye::
|
||
* GNU Guix::
|
||
|
||
Enable and load
|
||
|
||
* The require-theme for built-in Emacs themes::
|
||
* Sample configuration with and without use-package::
|
||
* Differences between loading and enabling::
|
||
|
||
Customization options
|
||
|
||
* Custom reload theme:: Toggle auto-reload of the theme when setting custom variables
|
||
* Disable other themes:: Determine whether loading a Modus themes disables all others
|
||
* Bold constructs:: Toggle bold constructs in code
|
||
* Italic constructs:: Toggle italic font constructs in code
|
||
* Mixed fonts:: Toggle mixing of font families
|
||
* Command prompts:: Control the style of command prompts
|
||
* Completion UIs:: Choose among several styles for completion UIs
|
||
* Org mode blocks:: Choose among plain, gray, or tinted backgrounds
|
||
* Heading styles:: Choose among several styles, also per heading level
|
||
* UI typeface:: Toggle the use of variable-pitch across the User Interface
|
||
* Palette overrides:: Refashion color values and/or semantic color mappings
|
||
|
||
Advanced customization
|
||
|
||
* Palette override presets::
|
||
* Stylistic variants using palette overrides::
|
||
* More accurate colors in terminal emulators::
|
||
* Range of color with terminal emulators::
|
||
* Preview theme colors::
|
||
* Per-theme customization settings::
|
||
* Get a single color from the palette::
|
||
* Use theme colors in code with modus-themes-with-colors::
|
||
* Do not extend the region background::
|
||
* Add padding to mode line::
|
||
* Remap face with local value::
|
||
* Font configurations for Org and others::
|
||
* Configure bold and italic faces::
|
||
* Custom Org todo keyword and priority faces::
|
||
* Custom Org emphasis faces::
|
||
* Update Org block delimiter fontification::
|
||
* Measure color contrast::
|
||
* Load theme depending on time of day::
|
||
* Backdrop for pdf-tools::
|
||
* Toggle themes without reloading them::
|
||
* A theme-agnostic hook for theme loading::
|
||
* Use more spacious margins or padding in Emacs frames::
|
||
* Custom hl-todo colors::
|
||
* Add support for solaire-mode::
|
||
|
||
Stylistic variants using palette overrides
|
||
|
||
* Make the mode line borderless::
|
||
* Make the active mode line colorful::
|
||
* Make the tab bar more or less colorful::
|
||
* Make the fringe invisible or another color::
|
||
* Make links use subtle or no underlines::
|
||
* Make prompts more or less colorful::
|
||
* Make completion matches more or less colorful::
|
||
* Make comments yellow and strings green::
|
||
* Make code syntax use the old alt-syntax style::
|
||
* Make use of alternative styles for code syntax::
|
||
* Make matching parenthesis more or less intense::
|
||
* Make box buttons more or less gray::
|
||
* Make TODO and DONE more or less intense::
|
||
* Make headings more or less colorful::
|
||
* Make Org agenda more or less colorful::
|
||
* Make inline code in prose use alternative styles::
|
||
* Make mail citations and headers more or less colorful::
|
||
* Make the region preserve text colors, plus other styles: Make the region preserve text colors plus other styles.
|
||
* Make mouse highlights more or less colorful::
|
||
* Make language underlines less colorful::
|
||
* Make line numbers use alternative styles::
|
||
* Make diffs use only a foreground::
|
||
* Make deuteranopia diffs red and blue instead of yellow and blue::
|
||
* Make the themes look like what the maintainer uses::
|
||
|
||
Face coverage
|
||
|
||
* Supported packages:: Full list of covered face groups
|
||
* Indirectly covered packages::
|
||
|
||
Notes on individual packages
|
||
|
||
* Note on calendar.el weekday and weekend colors: Note on calendarel weekday and weekend colors.
|
||
* Note on git-gutter in Doom Emacs::
|
||
* Note on php-mode multiline comments::
|
||
* Note on underlines in compilation buffers::
|
||
* Note on inline Latex in Org buffers::
|
||
* Note on dimmer.el: Note on dimmerel.
|
||
* Note on display-fill-column-indicator-mode::
|
||
* Note on highlight-parentheses.el: Note on highlight-parenthesesel.
|
||
* Note on mmm-mode.el background colors: Note on mmm-modeel background colors.
|
||
* Note for prism::
|
||
* Note on company-mode overlay pop-up::
|
||
* Note on ERC escaped color sequences::
|
||
* Note on powerline or spaceline::
|
||
* Note on SHR colors::
|
||
* Note on SHR fonts::
|
||
* Note on Ement colors and fonts::
|
||
* Note on pdf-tools link hints::
|
||
* Note on the Notmuch logo::
|
||
* Note on goto-address-mode faces::
|
||
|
||
Frequently Asked Questions
|
||
|
||
* Is the contrast ratio about adjacent colors?::
|
||
* What does it mean to avoid exaggerations?::
|
||
* Why are colors mostly variants of blue, magenta, cyan?: Why are colors mostly variants of blue magenta cyan?.
|
||
* What is the best setup for legibility?::
|
||
* Are these color schemes?::
|
||
* Port the Modus themes to other platforms?::
|
||
|
||
Contributing
|
||
|
||
* Sources of the themes::
|
||
* Issues you can help with::
|
||
* Patches require copyright assignment to the FSF::
|
||
|
||
Indices
|
||
|
||
* Function index::
|
||
* Variable index::
|
||
* Concept index::
|
||
|
||
|
||
|
||
File: modus-themes.info, Node: Overview, Next: Installation, Prev: Top, Up: Top
|
||
|
||
1 Overview
|
||
**********
|
||
|
||
The Modus themes are designed for accessible readability. They conform
|
||
with the highest standard for color contrast between combinations of
|
||
background and foreground values. For small sized text, this
|
||
corresponds to the WCAG AAA standard, which specifies a minimum rate of
|
||
distance in relative luminance of 7:1.
|
||
|
||
The Modus themes consist of eight themes, divided into four
|
||
subgroups.
|
||
|
||
Main themes
|
||
‘modus-operandi’ is the project’s main light theme, while
|
||
‘modus-vivendi’ is its dark counterpart. These two themes are part
|
||
of the project since its inception. They are designed to cover a
|
||
broad range of needs and are, in the opinion of the author, the
|
||
reference for what a highly legible “default” theme should look
|
||
like.
|
||
|
||
Tinted themes
|
||
‘modus-operandi-tinted’ and ‘modus-vivendi-tinted’ are variants of
|
||
the two main themes. They slightly tone down the intensity of the
|
||
background and provide a bit more color variety.
|
||
‘modus-operandi-tinted’ has a set of base tones that are shades of
|
||
light ochre (earthly colors), while ‘modus-vivendi-tinted’ gives a
|
||
night sky impression.
|
||
|
||
Deuteranopia themes
|
||
‘modus-operandi-deuteranopia’ and its companion
|
||
‘modus-vivendi-deuteranopia’ are optimized for users with red-green
|
||
color deficiency. This means that they do not use red and green
|
||
hues for color-coding purposes, such as for diff removed and added
|
||
lines. Instead, they implement colors that are discernible by
|
||
users with deueteranopia or deuteranomaly (mostly yellow and blue
|
||
hues).
|
||
|
||
Tritanopia themes
|
||
‘modus-operandi-tritanopia’ and its counterpart
|
||
‘modus-vivendi-tritanopia’ are optimized for users with blue-yellow
|
||
color deficiency. The idea is the same as with the deuteranopia
|
||
variants: color coding relies only on hues that are accessible to
|
||
people with tritanopia or tritanomaly, namely, shades of red and
|
||
cyan.
|
||
|
||
To ensure that users have a consistently accessible experience, the
|
||
themes strive to achieve as close to full face coverage as possible,
|
||
while still targeting a curated list of well-maintained packages (*note
|
||
Face coverage::).
|
||
|
||
The overarching objective of this project is to always offer
|
||
accessible color combinations. There shall never be a compromise on
|
||
this principle. If there arises an inescapable trade-off between
|
||
usability and stylistic considerations, we will always opt for the
|
||
former.
|
||
|
||
Starting with version 0.12.0 and onwards, the themes are built into
|
||
GNU Emacs.
|
||
|
||
* Menu:
|
||
|
||
* How do the themes look like::
|
||
* Learn about the latest changes::
|
||
|
||
|
||
File: modus-themes.info, Node: How do the themes look like, Next: Learn about the latest changes, Up: Overview
|
||
|
||
1.1 How do the themes look like
|
||
===============================
|
||
|
||
Check the web page with the screen shots
|
||
(https://protesilaos.com/emacs/modus-themes-pictures/). Note that the
|
||
themes are highly customizable (*note Customization options::).
|
||
|
||
|
||
File: modus-themes.info, Node: Learn about the latest changes, Prev: How do the themes look like, Up: Overview
|
||
|
||
1.2 Learn about the latest changes
|
||
==================================
|
||
|
||
Please refer to the web page with the change log
|
||
(https://protesilaos.com/emacs/modus-themes-changelog). It is
|
||
comprehensive and covers everything that goes into every tagged release
|
||
of the themes.
|
||
|
||
|
||
File: modus-themes.info, Node: Installation, Next: Enable and load, Prev: Overview, Up: Top
|
||
|
||
2 Installation
|
||
**************
|
||
|
||
The Modus themes are distributed with Emacs starting with version 28.1.
|
||
On older versions of Emacs, they can be installed using Emacs’ package
|
||
manager or manually from their code repository. There also exist
|
||
packages for distributions of GNU/Linux.
|
||
|
||
Emacs 28 ships with ‘modus-themes’ version ‘1.6.0’. Emacs 29
|
||
includes version ‘3.0.0’. Emacs 30 provides a newer, refactored version
|
||
that thoroughly refashions how the themes are implemented and
|
||
customized. Such major versions are not backward-compatible due to the
|
||
limited resources at the maintainer’s disposal to support multiple
|
||
versions of Emacs and of the themes across the years.
|
||
|
||
* Menu:
|
||
|
||
* Install manually from source::
|
||
* Install from the archives::
|
||
* Install on GNU/Linux::
|
||
* Dealing with byte compilation errors::
|
||
|
||
|
||
File: modus-themes.info, Node: Install manually from source, Next: Install from the archives, Up: Installation
|
||
|
||
2.1 Install manually from source
|
||
================================
|
||
|
||
In the following example, we are assuming that your Emacs files are
|
||
stored in ‘~/.emacs.d’ and that you want to place the Modus themes in
|
||
‘~/.emacs.d/modus-themes’.
|
||
|
||
1. Get the source and store it in the desired path by running the
|
||
following in the command line shell:
|
||
|
||
$ git clone https://gitlab.com/protesilaos/modus-themes.git ~/.emacs.d/modus-themes
|
||
|
||
1. Add that path to your known Elisp libraries’ list, by placing this
|
||
snippet of Emacs Lisp in your init file (e.g. ‘init.el’):
|
||
|
||
(add-to-list 'load-path "~/.emacs.d/modus-themes")
|
||
|
||
The themes are now ready to be used: *note Enable and load::.
|
||
|
||
|
||
File: modus-themes.info, Node: Install from the archives, Next: Install on GNU/Linux, Prev: Install manually from source, Up: Installation
|
||
|
||
2.2 Install from the archives
|
||
=============================
|
||
|
||
The ‘modus-themes’ package is available from the GNU ELPA archive, which
|
||
is configured by default.
|
||
|
||
Prior to querying any package archive, make sure to update the index,
|
||
with ‘M-x package-refresh-contents’. Then all you need to do is type
|
||
‘M-x package-install’ and specify the ‘modus-themes’.
|
||
|
||
Once installed, the themes are ready to be used: *note Enable and
|
||
load::.
|
||
|
||
|
||
File: modus-themes.info, Node: Install on GNU/Linux, Next: Dealing with byte compilation errors, Prev: Install from the archives, Up: Installation
|
||
|
||
2.3 Install on GNU/Linux
|
||
========================
|
||
|
||
The themes are also available from the archives of some distributions of
|
||
GNU/Linux. These should correspond to a tagged release rather than
|
||
building directly from the latest Git commit. It all depends on the
|
||
distro’s packaging policies.
|
||
|
||
* Menu:
|
||
|
||
* Debian 11 Bullseye::
|
||
* GNU Guix::
|
||
|
||
|
||
File: modus-themes.info, Node: Debian 11 Bullseye, Next: GNU Guix, Up: Install on GNU/Linux
|
||
|
||
2.3.1 Debian 11 Bullseye
|
||
------------------------
|
||
|
||
The themes are part of Debian 11 Bullseye. Get them with:
|
||
|
||
sudo apt install elpa-modus-themes
|
||
|
||
They are now ready to be used: *note Enable and load::.
|
||
|
||
NOTE that Debian’s package is severely out-of-date as of this writing
|
||
2022-07-24 09:57 +0300.
|
||
|
||
|
||
File: modus-themes.info, Node: GNU Guix, Prev: Debian 11 Bullseye, Up: Install on GNU/Linux
|
||
|
||
2.3.2 GNU Guix
|
||
--------------
|
||
|
||
Users of Guix can get the themes with this command:
|
||
|
||
guix package -i emacs-modus-themes
|
||
|
||
They are now ready to be used: *note Enable and load::.
|
||
|
||
|
||
File: modus-themes.info, Node: Dealing with byte compilation errors, Prev: Install on GNU/Linux, Up: Installation
|
||
|
||
2.4 Dealing with byte compilation errors
|
||
========================================
|
||
|
||
From time to time, we receive bug reports pertaining to errors with byte
|
||
compilation. These seldom have to do with faulty code in the themes: it
|
||
might be a shortcoming of ‘package.el’, some regression in the current
|
||
development target of Emacs, a misconfiguration in an otherwise exotic
|
||
setup, and the like.
|
||
|
||
The common solution with a stable version of Emacs is to:
|
||
|
||
1. Delete the ‘modus-themes’ package.
|
||
2. Close the current Emacs session.
|
||
3. Install the ‘modus-themes’ again.
|
||
|
||
For those building Emacs directly from source, the solution may
|
||
involve reverting to an earlier commit in emacs.git.
|
||
|
||
At any rate, if you encounter such an issue please report it: we will
|
||
either fix the bug on our end if it is truly ours, or help forward it to
|
||
the relevant upstream maintainer. Whatever you do, please understand
|
||
that a build failure does not mean we are necessarily doing something
|
||
wrong.
|
||
|
||
*note Issues you can help with::.
|
||
|
||
|
||
File: modus-themes.info, Node: Enable and load, Next: Customization options, Prev: Installation, Up: Top
|
||
|
||
3 Enable and load
|
||
*****************
|
||
|
||
NOTE that Emacs can load multiple themes, which typically produces
|
||
undesirable results and undoes the work of the designer. Use the
|
||
‘disable-theme’ command if you are trying other themes beside the Modus
|
||
collection (*note Option for disabling other themes while loading Modus:
|
||
Disable other themes.).
|
||
|
||
Users of the built-in themes cannot ‘require’ the package as usual
|
||
because there is no package to speak of. Instead, things are simpler as
|
||
built-in themes are considered safe. All one needs is to load the theme
|
||
of their preference by adding either form to their init file:
|
||
|
||
(load-theme 'modus-operandi) ; Light theme
|
||
(load-theme 'modus-vivendi) ; Dark theme
|
||
|
||
Remember that the Modus themes are six themes (*note Overview::).
|
||
Adapt the above snippet accordingly.
|
||
|
||
Users of packaged variants of the themes must add a few more lines to
|
||
ensure that everything works as intended. First, one has to require the
|
||
main library before loading one of the themes:
|
||
|
||
(require 'modus-themes)
|
||
|
||
One can activate a theme with something like the following
|
||
expression, replacing ‘modus-operandi’ with their preferred Modus theme:
|
||
|
||
(load-theme 'modus-operandi :no-confirm)
|
||
|
||
Changes to the available customization options must always be
|
||
evaluated before loading a theme (*note Customization Options:
|
||
Customization options.). Reload a theme for new changes to take effect.
|
||
|
||
This is how a basic setup could look like (*note The require-theme
|
||
for built-in Emacs themes: The require-theme for built-in Emacs
|
||
themes.):
|
||
|
||
;;; For the built-in themes which cannot use `require'.
|
||
(require-theme 'modus-themes)
|
||
|
||
;; Add all your customizations prior to loading the themes.
|
||
(setq modus-themes-italic-constructs t
|
||
modus-themes-bold-constructs nil)
|
||
|
||
;; Load the theme of your choice.
|
||
(load-theme 'modus-operandi)
|
||
|
||
;; Optionally define a key to switch between Modus themes. Also check
|
||
;; the user option `modus-themes-to-toggle'.
|
||
(define-key global-map (kbd "<f5>") #'modus-themes-toggle)
|
||
|
||
|
||
|
||
;;; For packaged versions which must use `require'.
|
||
|
||
(require 'modus-themes)
|
||
|
||
;; Add all your customizations prior to loading the themes
|
||
(setq modus-themes-italic-constructs t
|
||
modus-themes-bold-constructs nil)
|
||
|
||
;; Load the theme of your choice.
|
||
(load-theme 'modus-operandi :no-confirm)
|
||
|
||
(define-key global-map (kbd "<f5>") #'modus-themes-toggle)
|
||
|
||
*note Sample configuration with and without use-package::.
|
||
|
||
* Menu:
|
||
|
||
* The require-theme for built-in Emacs themes::
|
||
* Sample configuration with and without use-package::
|
||
* Differences between loading and enabling::
|
||
|
||
|
||
File: modus-themes.info, Node: The require-theme for built-in Emacs themes, Next: Sample configuration with and without use-package, Up: Enable and load
|
||
|
||
3.1 The ‘require-theme’ for built-in Emacs themes
|
||
=================================================
|
||
|
||
The version of the Modus themes that is included in Emacs CANNOT use the
|
||
standard ‘require’. This is because the built-in themes are not
|
||
included in the ‘load-path’ (not my decision). The ‘require-theme’
|
||
function must be used in this case as a replacement. For example:
|
||
|
||
(require-theme 'modus-themes)
|
||
|
||
;; All customizations here
|
||
(setq modus-themes-bold-constructs t
|
||
modus-themes-italic-constructs t)
|
||
|
||
;; Maybe define some palette overrides, such as by using our presets
|
||
(setq modus-themes-common-palette-overrides
|
||
modus-themes-preset-overrides-intense)
|
||
|
||
;; Load the theme of choice (built-in themes are always "safe" so they
|
||
;; do not need the `no-require' argument of `load-theme').
|
||
(load-theme 'modus-operandi)
|
||
|
||
(define-key global-map (kbd "<f5>") #'modus-themes-toggle)
|
||
|
||
|
||
File: modus-themes.info, Node: Sample configuration with and without use-package, Next: Differences between loading and enabling, Prev: The require-theme for built-in Emacs themes, Up: Enable and load
|
||
|
||
3.2 Sample configuration with and without use-package
|
||
=====================================================
|
||
|
||
What follows is a variant of what we demonstrate in the previous section
|
||
(*note Enable and load::).
|
||
|
||
It is common for Emacs users to rely on ‘use-package’ for declaring
|
||
package configurations in their setup. We use this as an example:
|
||
|
||
;;; For the built-in themes which cannot use `require'.
|
||
(use-package emacs
|
||
:config
|
||
(require-theme 'modus-themes) ; `require-theme' is ONLY for the built-in Modus themes
|
||
|
||
;; Add all your customizations prior to loading the themes
|
||
(setq modus-themes-italic-constructs t
|
||
modus-themes-bold-constructs nil)
|
||
|
||
;; Maybe define some palette overrides, such as by using our presets
|
||
(setq modus-themes-common-palette-overrides
|
||
modus-themes-preset-overrides-intense)
|
||
|
||
;; Load the theme of your choice.
|
||
(load-theme 'modus-operandi)
|
||
|
||
(define-key global-map (kbd "<f5>") #'modus-themes-toggle))
|
||
|
||
|
||
|
||
;;; For packaged versions which must use `require'.
|
||
(use-package modus-themes
|
||
:ensure t
|
||
:config
|
||
;; Add all your customizations prior to loading the themes
|
||
(setq modus-themes-italic-constructs t
|
||
modus-themes-bold-constructs nil)
|
||
|
||
;; Maybe define some palette overrides, such as by using our presets
|
||
(setq modus-themes-common-palette-overrides
|
||
modus-themes-preset-overrides-intense)
|
||
|
||
;; Load the theme of your choice.
|
||
(load-theme 'modus-operandi)
|
||
|
||
(define-key global-map (kbd "<f5>") #'modus-themes-toggle))
|
||
|
||
The same without ‘use-package’:
|
||
|
||
(require 'modus-themes) ; OR for the built-in themes: (require-theme 'modus-themes)
|
||
|
||
;; Add all your customizations prior to loading the themes
|
||
(setq modus-themes-italic-constructs t
|
||
modus-themes-bold-constructs nil)
|
||
|
||
;; Maybe define some palette overrides, such as by using our presets
|
||
(setq modus-themes-common-palette-overrides
|
||
modus-themes-preset-overrides-intense)
|
||
|
||
;; Load the theme of your choice:
|
||
(load-theme 'modus-operandi :no-confirm)
|
||
|
||
(define-key global-map (kbd "<f5>") #'modus-themes-toggle)
|
||
|
||
*note Differences between loading and enabling::.
|
||
|
||
Note: make sure not to customize the variable
|
||
‘custom-theme-load-path’ or ‘custom-theme-directory’ after the themes’
|
||
package declaration. That will lead to failures in loading the files.
|
||
If either or both of those variables need to be changed, their values
|
||
should be defined before the package declaration of the themes.
|
||
|
||
*note Make the themes look like what the maintainer uses::
|
||
|
||
|
||
File: modus-themes.info, Node: Differences between loading and enabling, Prev: Sample configuration with and without use-package, Up: Enable and load
|
||
|
||
3.3 Differences between loading and enabling
|
||
============================================
|
||
|
||
The reason we recommend ‘load-theme’ instead of the other option of
|
||
‘enable-theme’ is that the former does a kind of “reset” on the face
|
||
specs. It quite literally loads (or reloads) the theme. Whereas the
|
||
‘enable-theme’ function simply puts an already loaded theme to the top
|
||
of the list of enabled items, re-using whatever state was last loaded.
|
||
|
||
As such, ‘load-theme’ reads all customizations that may happen during
|
||
any given Emacs session: even after the initial setup of a theme.
|
||
Examples are calls to ‘custom-set-faces’, as well as new values assigned
|
||
to the options the Modus themes provide (*note Customization Options:
|
||
Customization options.).
|
||
|
||
Our tests show that ‘enable-theme’ does not read such variables anew,
|
||
so it might appear to the unsuspecting user that the themes are somehow
|
||
broken whenever they try to assign a new value to a customization option
|
||
or some face.
|
||
|
||
This “reset” that ‘load-theme’ brings about does, however, come at
|
||
the cost of being somewhat slower than ‘enable-theme’. Users who have a
|
||
stable setup and who seldom update their variables during a given Emacs
|
||
session, are better off using something like this:
|
||
|
||
(require 'modus-themes)
|
||
|
||
;; Activate your desired themes here
|
||
(load-theme 'modus-operandi t t)
|
||
(load-theme 'modus-vivendi t t)
|
||
|
||
;; Enable the preferred one
|
||
(enable-theme 'modus-operandi)
|
||
|
||
*note Toggle themes without reloading them::.
|
||
|
||
*note Sample configuration with and without use-package::.
|
||
|
||
With the above granted, other sections of the manual discuss how to
|
||
configure custom faces, where ‘load-theme’ is expected, though
|
||
‘enable-theme’ could still apply in stable setups:
|
||
|
||
*note Use theme colors in code with modus-themes-with-colors::.
|
||
|
||
|
||
File: modus-themes.info, Node: Customization options, Next: Advanced customization, Prev: Enable and load, Up: Top
|
||
|
||
4 Customization options
|
||
***********************
|
||
|
||
The Modus themes are highly configurable, though they should work well
|
||
without any further tweaks. We provide a variety of user options. The
|
||
following code block provides an overview. In addition to those
|
||
variables, the themes support a comprehensive system of overrides: it
|
||
can be used to make thoroughgoing changes to the looks of the themes
|
||
(*note Option for palette overrides: Palette overrides.). We document
|
||
everything at length in the pages of this manual and also provide
|
||
ready-to-use code samples.
|
||
|
||
Remember that all customization options must be evaluated before
|
||
loading a theme (*note Enable and load::). If the theme is already
|
||
active, it must be reloaded for changes to take effect.
|
||
|
||
;; In all of the following, WEIGHT is a symbol such as `semibold',
|
||
;; `light', `bold', or anything mentioned in `modus-themes-weights'.
|
||
(setq modus-themes-italic-constructs t
|
||
modus-themes-bold-constructs nil
|
||
modus-themes-mixed-fonts t
|
||
modus-themes-variable-pitch-ui nil
|
||
modus-themes-custom-auto-reload t
|
||
modus-themes-disable-other-themes t
|
||
|
||
;; Options for `modus-themes-prompts' are either nil (the
|
||
;; default), or a list of properties that may include any of those
|
||
;; symbols: `italic', `WEIGHT'
|
||
modus-themes-prompts '(italic bold)
|
||
|
||
;; The `modus-themes-completions' is an alist that reads two
|
||
;; keys: `matches', `selection'. Each accepts a nil value (or
|
||
;; empty list) or a list of properties that can include any of
|
||
;; the following (for WEIGHT read further below):
|
||
;;
|
||
;; `matches' :: `underline', `italic', `WEIGHT'
|
||
;; `selection' :: `underline', `italic', `WEIGHT'
|
||
modus-themes-completions
|
||
'((matches . (extrabold))
|
||
(selection . (semibold italic text-also)))
|
||
|
||
modus-themes-org-blocks 'gray-background ; {nil,'gray-background,'tinted-background}
|
||
|
||
;; The `modus-themes-headings' is an alist: read the manual's
|
||
;; node about it or its doc string. Basically, it supports
|
||
;; per-level configurations for the optional use of
|
||
;; `variable-pitch' typography, a height value as a multiple of
|
||
;; the base font size (e.g. 1.5), and a `WEIGHT'.
|
||
modus-themes-headings
|
||
'((1 . (variable-pitch 1.5))
|
||
(2 . (1.3))
|
||
(agenda-date . (1.3))
|
||
(agenda-structure . (variable-pitch light 1.8))
|
||
(t . (1.1))))
|
||
|
||
;; Remember that more (MUCH MORE) can be done with overrides, which we
|
||
;; document extensively in this manual.
|
||
|
||
* Menu:
|
||
|
||
* Custom reload theme:: Toggle auto-reload of the theme when setting custom variables
|
||
* Disable other themes:: Determine whether loading a Modus themes disables all others
|
||
* Bold constructs:: Toggle bold constructs in code
|
||
* Italic constructs:: Toggle italic font constructs in code
|
||
* Mixed fonts:: Toggle mixing of font families
|
||
* Command prompts:: Control the style of command prompts
|
||
* Completion UIs:: Choose among several styles for completion UIs
|
||
* Org mode blocks:: Choose among plain, gray, or tinted backgrounds
|
||
* Heading styles:: Choose among several styles, also per heading level
|
||
* UI typeface:: Toggle the use of variable-pitch across the User Interface
|
||
* Palette overrides:: Refashion color values and/or semantic color mappings
|
||
|
||
|
||
File: modus-themes.info, Node: Custom reload theme, Next: Disable other themes, Up: Customization options
|
||
|
||
4.1 Option for reloading the theme on custom change
|
||
===================================================
|
||
|
||
Brief: Toggle reloading of the active theme when an option is changed
|
||
through the Custom UI.
|
||
|
||
Symbol: ‘modus-themes-custom-auto-reload’ (‘boolean’ type)
|
||
|
||
Possible values:
|
||
|
||
1. ‘nil’
|
||
2. ‘t’ (default)
|
||
|
||
All theme user options take effect when a theme is loaded. Any
|
||
subsequent changes require the theme to be reloaded.
|
||
|
||
When this variable has a non-‘nil’ value, any change made via the
|
||
Custom UI or related functions such as ‘customize-set-variable’ and
|
||
‘setopt’ (Emacs 29), will trigger a reload automatically.
|
||
|
||
With a ‘nil’ value, changes to user options have no further
|
||
consequences: the user must manually reload the theme (*note Enable and
|
||
load::).
|
||
|
||
|
||
File: modus-themes.info, Node: Disable other themes, Next: Bold constructs, Prev: Custom reload theme, Up: Customization options
|
||
|
||
4.2 Option for disabling other themes while loading Modus
|
||
=========================================================
|
||
|
||
Brief: Disable all other themes when loading a Modus theme.
|
||
|
||
Symbol: ‘modus-themes-disable-other-themes’ (‘boolean’ type)
|
||
|
||
Possible values:
|
||
|
||
1. ‘nil’
|
||
2. ‘t’ (default)
|
||
|
||
When the value is non-‘nil’, the commands ‘modus-themes-toggle’ and
|
||
‘modus-themes-select’, as well as the ‘modus-themes-load-theme’
|
||
function, will disable all other themes while loading the specified
|
||
Modus theme. This is done to ensure that Emacs does not blend two or
|
||
more themes: such blends lead to awkward results that undermine the work
|
||
of the designer.
|
||
|
||
When the value is ‘nil’, the aforementioned commands and function
|
||
will only disable other themes within the Modus collection.
|
||
|
||
This option is provided because Emacs themes are not necessarily
|
||
limited to colors/faces: they can consist of an arbitrary set of
|
||
customizations. Users who use such customization bundles must set this
|
||
variable to a ‘nil’ value.
|
||
|
||
|
||
File: modus-themes.info, Node: Bold constructs, Next: Italic constructs, Prev: Disable other themes, Up: Customization options
|
||
|
||
4.3 Option for more bold constructs
|
||
===================================
|
||
|
||
Brief: Use bold for code syntax highlighting and related.
|
||
|
||
Symbol: ‘modus-themes-bold-constructs’ (‘boolean’ type)
|
||
|
||
Possible values:
|
||
|
||
1. ‘nil’ (default)
|
||
2. ‘t’
|
||
|
||
The default is to use a bold typographic weight only when it is
|
||
required.
|
||
|
||
With a non-‘nil’ value (‘t’) display several syntactic constructs in
|
||
bold weight. This concerns keywords and other important aspects of code
|
||
syntax. It also affects certain mode line indicators and command
|
||
prompts.
|
||
|
||
Advanced users may also want to configure the exact attributes of the
|
||
‘bold’ face.
|
||
|
||
*note Configure bold and italic faces::.
|
||
|
||
|
||
File: modus-themes.info, Node: Italic constructs, Next: Mixed fonts, Prev: Bold constructs, Up: Customization options
|
||
|
||
4.4 Option for more italic constructs
|
||
=====================================
|
||
|
||
Brief: Use italics for code syntax highlighting and related.
|
||
|
||
Symbol: ‘modus-themes-italic-constructs’ (‘boolean’ type)
|
||
|
||
Possible values:
|
||
|
||
1. ‘nil’ (default)
|
||
2. ‘t’
|
||
|
||
The default is to not use slanted text forms (italics) unless it is
|
||
absolutely necessary.
|
||
|
||
With a non-‘nil’ value (‘t’) choose to render more faces in italics.
|
||
This typically affects documentation strings and code comments.
|
||
|
||
Advanced users may also want to configure the exact attributes of the
|
||
‘italic’ face.
|
||
|
||
*note Configure bold and italic faces::.
|
||
|
||
|
||
File: modus-themes.info, Node: Mixed fonts, Next: Command prompts, Prev: Italic constructs, Up: Customization options
|
||
|
||
4.5 Option for font mixing
|
||
==========================
|
||
|
||
Brief: Toggle the use of monospaced fonts for spacing-sensitive
|
||
constructs (affects font families).
|
||
|
||
Symbol: ‘modus-themes-mixed-fonts’ (‘boolean’ type)
|
||
|
||
Possible values:
|
||
|
||
1. ‘nil’ (default)
|
||
2. ‘t’
|
||
|
||
When set to non-‘nil’ (‘t’), configure some spacing-sensitive faces
|
||
like Org tables and code blocks to always inherit from the ‘fixed-pitch’
|
||
face. This is to ensure that certain constructs like code blocks and
|
||
tables remain monospaced even when users opt for a mode that remaps
|
||
typeface families, such as the built-in ‘M-x variable-pitch-mode’.
|
||
Otherwise the layout can appear broken, due to how spacing is done.
|
||
|
||
For a consistent experience, user may need to specify the font family
|
||
of the ‘fixed-pitch’ face.
|
||
|
||
*note Font configurations for Org and others::.
|
||
|
||
|
||
File: modus-themes.info, Node: Command prompts, Next: Completion UIs, Prev: Mixed fonts, Up: Customization options
|
||
|
||
4.6 Option for command prompt styles
|
||
====================================
|
||
|
||
Brief: Control the style of command prompts (e.g. minibuffer, shell,
|
||
IRC clients).
|
||
|
||
Symbol: ‘modus-themes-prompts’ (‘choice’ type, list of properties)
|
||
|
||
Possible values are expressed as a list of properties (default is
|
||
‘nil’ or an empty list). The list can include any of the following
|
||
symbols:
|
||
|
||
• ‘italic’
|
||
• ‘italic’
|
||
• A font weight, which must be supported by the underlying typeface:
|
||
• ‘thin’
|
||
• ‘ultralight’
|
||
• ‘extralight’
|
||
• ‘light’
|
||
• ‘semilight’
|
||
• ‘regular’
|
||
• ‘medium’
|
||
• ‘semibold’
|
||
• ‘bold’
|
||
• ‘heavy’
|
||
• ‘extrabold’
|
||
• ‘ultrabold’
|
||
|
||
The default (a ‘nil’ value or an empty list) means to only use a
|
||
subtle colored foreground color.
|
||
|
||
The ‘italic’ property adds a slant to the font’s forms (italic or
|
||
oblique forms, depending on the typeface).
|
||
|
||
The symbol of a font weight attribute such as ‘light’, ‘semibold’, et
|
||
cetera, adds the given weight to links. Valid symbols are defined in
|
||
the variable ‘modus-themes-weights’. The absence of a weight means that
|
||
the one of the underlying text will be used.
|
||
|
||
Combinations of any of those properties are expressed as a list, like
|
||
in these examples:
|
||
|
||
(bold italic)
|
||
(italic semibold)
|
||
|
||
The order in which the properties are set is not significant.
|
||
|
||
In user configuration files the form may look like this:
|
||
|
||
(setq modus-themes-prompts '(extrabold italic))
|
||
|
||
*note Make prompts more or less colorful::.
|
||
|
||
|
||
File: modus-themes.info, Node: Completion UIs, Next: Org mode blocks, Prev: Command prompts, Up: Customization options
|
||
|
||
4.7 Option for completion framework aesthetics
|
||
==============================================
|
||
|
||
Brief: Set the overall style of completion framework interfaces.
|
||
|
||
Symbol: ‘modus-themes-completions’ (‘alist’ type properties)
|
||
|
||
This affects Company, Corfu, Flx, Icomplete/Fido, Ido, Ivy,
|
||
Orderless, Vertico, and the standard ‘*Completions*’ buffer. The value
|
||
is an alist of expressions, each of which takes the form of ‘(KEY .
|
||
LIST-OF-PROPERTIES)’. ‘KEY’ is a symbol, while ‘PROPERTIES’ is a list.
|
||
Here is a sample, followed by a description of the particularities:
|
||
|
||
(setq modus-themes-completions
|
||
'((matches . (extrabold underline))
|
||
(selection . (semibold italic))))
|
||
|
||
The ‘matches’ key refers to the highlighted characters that
|
||
correspond to the user’s input. When its properties are ‘nil’ or an
|
||
empty list, matching characters in the user interface will have a bold
|
||
weight and a colored foreground. The list of properties may include any
|
||
of the following symbols regardless of the order they may appear in:
|
||
|
||
• ‘underline’ to draw a line below the characters;
|
||
|
||
• ‘italic’ to use a slanted font (italic or oblique forms);
|
||
|
||
• The symbol of a font weight attribute such as ‘light’, ‘semibold’,
|
||
et cetera. Valid symbols are defined in the variable
|
||
‘modus-themes-weights’. The absence of a weight means that bold
|
||
will be used.
|
||
|
||
The ‘selection’ key applies to the current line or currently matched
|
||
candidate, depending on the specifics of the user interface. When its
|
||
properties are ‘nil’ or an empty list, it has a subtle gray background,
|
||
a bold weight, and the base foreground value for the text. The list of
|
||
properties it accepts is as follows (order is not significant):
|
||
|
||
• ‘underline’ to draw a line below the characters;
|
||
|
||
• ‘italic’ to use a slanted font (italic or oblique forms);
|
||
|
||
• The symbol of a font weight attribute such as ‘light’, ‘semibold’,
|
||
et cetera. Valid symbols are defined in the variable
|
||
‘modus-themes-weights’. The absence of a weight means that bold
|
||
will be used.
|
||
|
||
Apart from specifying each key separately, a catch-all list is
|
||
accepted. This is only useful when the desired aesthetic is the same
|
||
across all keys that are not explicitly referenced. For example, this:
|
||
|
||
(setq modus-themes-completions
|
||
'((t . (extrabold underline))))
|
||
|
||
Is the same as:
|
||
|
||
(setq modus-themes-completions
|
||
'((matches . (extrabold underline))
|
||
(selection . (extrabold underline))))
|
||
|
||
*note Make completion matches more or less colorful::.
|
||
|
||
|
||
File: modus-themes.info, Node: Org mode blocks, Next: Heading styles, Prev: Completion UIs, Up: Customization options
|
||
|
||
4.8 Option for org-mode block styles
|
||
====================================
|
||
|
||
Brief: Set the overall style of Org code blocks, quotes, and the like.
|
||
|
||
Symbol: ‘modus-themes-org-blocks’ (‘choice’ type)
|
||
|
||
Possible values:
|
||
|
||
1. ‘nil’ (default)
|
||
2. ‘gray-background’
|
||
3. ‘tinted-background’
|
||
|
||
Option ‘nil’ (the default) means that the block has no background of
|
||
its own: it uses the one that applies to the rest of the buffer. In
|
||
this case, the delimiter lines have a gray color for their text, making
|
||
them look exactly like all other Org properties.
|
||
|
||
Option ‘gray-background’ applies a subtle gray background to the
|
||
block’s contents. It also affects the begin and end lines of the block
|
||
as they get another shade of gray as their background, which
|
||
differentiates them from the contents of the block. All background
|
||
colors extend to the edge of the window, giving the area a rectangular,
|
||
“blocky” presentation. If the begin/end lines do not extend in this
|
||
way, check the value of the Org user option
|
||
‘org-fontify-whole-block-delimiter-line’.
|
||
|
||
Option ‘tinted-background’ uses a colored background for the contents
|
||
of the block. The exact color value will depend on the programming
|
||
language and is controlled by the variable ‘org-src-block-faces’ (refer
|
||
to the theme’s source code for the current association list). For this
|
||
to take effect, the Org buffer needs to be restarted with
|
||
‘org-mode-restart’.
|
||
|
||
Code blocks use their major mode’s fontification (syntax
|
||
highlighting) only when the variable ‘org-src-fontify-natively’ is
|
||
non-‘nil’. While quote/verse blocks require setting
|
||
‘org-fontify-quote-and-verse-blocks’ to a non-‘nil’ value.
|
||
|
||
*note Update Org block delimiter fontification::.
|
||
|
||
|
||
File: modus-themes.info, Node: Heading styles, Next: UI typeface, Prev: Org mode blocks, Up: Customization options
|
||
|
||
4.9 Option for the headings’ overall style
|
||
==========================================
|
||
|
||
Brief: Heading styles with optional list of values per heading level.
|
||
|
||
Symbol: ‘modus-themes-headings’ (‘alist’ type, multiple properties)
|
||
|
||
This is an alist that accepts a ‘(KEY . LIST-OF-VALUES)’ combination.
|
||
The ‘KEY’ is either a number, representing the heading’s level (0
|
||
through 8) or ‘t’, which pertains to the fallback style. The named keys
|
||
‘agenda-date’ and ‘agenda-structure’ apply to the Org agenda.
|
||
|
||
Level 0 is a special heading: it is used for what counts as a
|
||
document title or equivalent, such as the ‘#+title’ construct we find in
|
||
Org files. Levels 1-8 are regular headings.
|
||
|
||
The ‘LIST-OF-VALUES’ covers symbols that refer to properties, as
|
||
described below. Here is a complete sample with various stylistic
|
||
combinations, followed by a presentation of all available properties:
|
||
|
||
(setq modus-themes-headings
|
||
'((1 . (variable-pitch 1.5))
|
||
(2 . (1.3))
|
||
(agenda-date . (1.3))
|
||
(agenda-structure . (variable-pitch light 1.8))
|
||
(t . (1.1))))
|
||
|
||
Properties:
|
||
|
||
• A font weight, which must be supported by the underlying typeface:
|
||
• ‘thin’
|
||
• ‘ultralight’
|
||
• ‘extralight’
|
||
• ‘light’
|
||
• ‘semilight’
|
||
• ‘regular’
|
||
• ‘medium’
|
||
• ‘semibold’
|
||
• ‘bold’ (default)
|
||
• ‘heavy’
|
||
• ‘extrabold’
|
||
• ‘ultrabold’
|
||
• A floating point as a height multiple of the default or a cons cell
|
||
in the form of ‘(height . FLOAT)’.
|
||
|
||
By default (a ‘nil’ value for this variable), all headings have a
|
||
bold typographic weight and use a desaturated text color.
|
||
|
||
A ‘variable-pitch’ property changes the font family of the heading to
|
||
that of the ‘variable-pitch’ face (normally a proportionately spaced
|
||
typeface).
|
||
|
||
The symbol of a weight attribute adjusts the font of the heading
|
||
accordingly, such as ‘light’, ‘semibold’, etc. Valid symbols are
|
||
defined in the variable ‘modus-themes-weights’. The absence of a weight
|
||
means that bold will be used by virtue of inheriting the ‘bold’ face.
|
||
|
||
*note Configure bold and italic faces::.
|
||
|
||
A number, expressed as a floating point (e.g. 1.5), adjusts the
|
||
height of the heading to that many times the base font size. The
|
||
default height is the same as 1.0, though it need not be explicitly
|
||
stated. Instead of a floating point, an acceptable value can be in the
|
||
form of a cons cell like ‘(height . FLOAT)’ or ‘(height FLOAT)’, where
|
||
FLOAT is the given number.
|
||
|
||
Combinations of any of those properties are expressed as a list, like
|
||
in these examples:
|
||
|
||
(semibold)
|
||
(variable-pitch semibold 1.3)
|
||
(variable-pitch semibold (height 1.3)) ; same as above
|
||
(variable-pitch semibold (height . 1.3)) ; same as above
|
||
|
||
The order in which the properties are set is not significant.
|
||
|
||
In user configuration files the form may look like this:
|
||
|
||
(setq modus-themes-headings
|
||
'((1 . (variable-pitch 1.5))
|
||
(2 . (1.3))
|
||
(agenda-date . (1.3))
|
||
(agenda-structure . (variable-pitch light 1.8))
|
||
(t . (1.1))))
|
||
|
||
When defining the styles per heading level, it is possible to pass a
|
||
non-‘nil’ value (‘t’) instead of a list of properties. This will retain
|
||
the original aesthetic for that level. For example:
|
||
|
||
(setq modus-themes-headings
|
||
'((1 . t) ; keep the default style
|
||
(2 . (semibold 1.2))
|
||
(t . (rainbow)))) ; style for all other headings
|
||
|
||
(setq modus-themes-headings
|
||
'((1 . (variable-pitch 1.5))
|
||
(2 . (semibold))
|
||
(t . t))) ; default style for all other levels
|
||
|
||
Note that the text color of headings, of their background, and
|
||
overline can all be set via the overrides. It is possible to have any
|
||
color combination for any heading level (something that could not be
|
||
done in older versions of the themes).
|
||
|
||
*note Option for palette overrides: Palette overrides.
|
||
|
||
*note Make headings more or less colorful::.
|
||
|
||
|
||
File: modus-themes.info, Node: UI typeface, Next: Palette overrides, Prev: Heading styles, Up: Customization options
|
||
|
||
4.10 Option for variable-pitch font in UI elements
|
||
==================================================
|
||
|
||
Brief: Toggle the use of proportionately spaced (‘variable-pitch’) fonts
|
||
in the User Interface.
|
||
|
||
Symbol: ‘modus-themes-variable-pitch-ui’ (‘boolean’ type)
|
||
|
||
Possible values:
|
||
|
||
1. ‘nil’ (default)
|
||
2. ‘t’
|
||
|
||
This option concerns User Interface elements that are under the
|
||
direct control of Emacs. In particular: the mode line, header line, tab
|
||
bar, and tab line.
|
||
|
||
The default is to use the same font as the rest of Emacs, which
|
||
usually is a monospaced family.
|
||
|
||
With a non-‘nil’ value (‘t’) apply a proportionately spaced typeface.
|
||
This is done by assigning the ‘variable-pitch’ face to the relevant
|
||
items.
|
||
|
||
*note Font configurations for Org and others::.
|
||
|
||
|
||
File: modus-themes.info, Node: Palette overrides, Prev: UI typeface, Up: Customization options
|
||
|
||
4.11 Option for palette overrides
|
||
=================================
|
||
|
||
This section describes palette overrides in detail. For a simpler
|
||
alternative, use the presets we provide (*note Palette override
|
||
presets::).
|
||
|
||
Each Modus theme specifies a color palette that declares named color
|
||
values and semantic color mappings:
|
||
|
||
• Named colors consist of a symbol and a string that specifies a
|
||
hexadecimal RGB value. For example: ‘(blue-warmer "#354fcf")’.
|
||
|
||
• The semantic color mappings associate an abstract construct with a
|
||
given named color from the palette, like ‘(heading-2
|
||
yellow-faint)’. Both elements of the list are symbols, though the
|
||
‘cadr’ (value) can be a string that specifies a color, such as
|
||
‘(heading-2 "#354fcf")’.
|
||
|
||
Both of those subsets can be overridden, thus refashioning the theme.
|
||
Overrides are either shared, by being stored in the user option
|
||
‘modus-themes-common-palette-overrides’, or they are specific to the
|
||
theme they name. In the latter case, the naming scheme of each palette
|
||
variable is ‘THEME-NAME-palette-overrides’, thus yielding:
|
||
|
||
• ‘modus-operandi-palette-overrides’
|
||
|
||
• ‘modus-operandi-deuteranopia-palette-overrides’
|
||
|
||
• ‘modus-operandi-tinted-palette-overrides’
|
||
|
||
• ‘modus-operandi-tritanopia-palette-overrides’
|
||
|
||
• ‘modus-vivendi-palette-overrides’
|
||
|
||
• ‘modus-vivendi-deuteranopia-palette-overrides’
|
||
|
||
• ‘modus-vivendi-tinted-palette-overrides’
|
||
|
||
• ‘modus-vivendi-tritanopia-palette-overrides’
|
||
|
||
Theme-specific overrides take precedence over the shared ones. It is
|
||
strongly advised that shared overrides do NOT alter color values, as
|
||
those will not be appropriate for both dark and light themes. Common
|
||
overrides are best limited to the semantic color mappings as those use
|
||
the color value that corresponds to the active theme (e.g. make the
|
||
cursor ‘blue-warmer’ in all themes, whatever the value of ‘blue-warmer’
|
||
is in each theme).
|
||
|
||
The value of any overrides’ variable must mirror a theme’s palette.
|
||
Palette variables are named after their theme as ‘THEME-NAME-palette’.
|
||
For example, the ‘modus-operandi-palette’ is like this:
|
||
|
||
(defconst modus-operandi-palette
|
||
'(
|
||
;;; Basic values
|
||
|
||
(bg-main "#ffffff")
|
||
(bg-dim "#f0f0f0")
|
||
(fg-main "#000000")
|
||
|
||
;; ...
|
||
|
||
(red "#a60000")
|
||
(red-warmer "#972500")
|
||
(red-cooler "#a0132f")
|
||
(red-faint "#7f0000")
|
||
(red-intense "#d00000")
|
||
|
||
;; ...
|
||
|
||
;;;; Mappings
|
||
|
||
;; ...
|
||
|
||
(cursor fg-main)
|
||
(builtin magenta-warmer)
|
||
(comment fg-dim)
|
||
(constant blue-cooler)
|
||
(docstring green-faint)
|
||
(fnname magenta)
|
||
(keyword magenta-cooler)
|
||
|
||
;; ...
|
||
))
|
||
|
||
The ‘modus-operandi-palette-overrides’ targets the entries that need
|
||
to be changed. For example, to make the main foreground color a dark
|
||
gray instead of pure black, use a shade of red for comments, and apply a
|
||
cyan hue to keywords:
|
||
|
||
(setq modus-operandi-palette-overrides
|
||
'((fg-main "#333333")
|
||
(comment red-faint)
|
||
(keyword cyan-cooler)))
|
||
|
||
Changes take effect upon theme reload (*note Custom reload theme::).
|
||
Overrides are removed by setting their variable to a ‘nil’ value.
|
||
|
||
The common accented foregrounds in each palette follow a predictable
|
||
naming scheme: ‘HUE{,-warmer,-cooler,-faint,-intense}’. ‘HUE’ is one of
|
||
the six basic colors: red, green, blue, yellow, magenta, cyan.
|
||
|
||
Named colors that are meant to be used as backgrounds contain ‘bg’ in
|
||
their name, such as ‘bg-red-intense’. While special purpose foregrounds
|
||
that are meant to be combined with such backgrounds, contain ‘fg’ in
|
||
their name, such as ‘fg-removed’ which complements ‘bg-removed’.
|
||
|
||
Named colors can be previewed, such as with the command
|
||
‘modus-themes-list-colors’ (*note Preview theme colors::).
|
||
|
||
For a video tutorial that users of all skill levels can approach,
|
||
watch:
|
||
<https://protesilaos.com/codelog/2022-12-17-modus-themes-v4-demo/>.
|
||
|
||
|
||
File: modus-themes.info, Node: Advanced customization, Next: Face coverage, Prev: Customization options, Up: Top
|
||
|
||
5 Advanced customization
|
||
************************
|
||
|
||
Unlike the predefined customization options which follow a clear pattern
|
||
of allowing the user to quickly specify their preference, the themes
|
||
also provide a more flexible, albeit difficult, mechanism to control
|
||
things with precision (*note Customization Options: Customization
|
||
options.).
|
||
|
||
This section is of interest only to users who are prepared to
|
||
maintain their own local tweaks and who are willing to deal with any
|
||
possible incompatibilities between versioned releases of the themes. As
|
||
such, they are labeled as “do-it-yourself” or “DIY”.
|
||
|
||
* Menu:
|
||
|
||
* Palette override presets::
|
||
* Stylistic variants using palette overrides::
|
||
* More accurate colors in terminal emulators::
|
||
* Range of color with terminal emulators::
|
||
* Preview theme colors::
|
||
* Per-theme customization settings::
|
||
* Get a single color from the palette::
|
||
* Use theme colors in code with modus-themes-with-colors::
|
||
* Do not extend the region background::
|
||
* Add padding to mode line::
|
||
* Remap face with local value::
|
||
* Font configurations for Org and others::
|
||
* Configure bold and italic faces::
|
||
* Custom Org todo keyword and priority faces::
|
||
* Custom Org emphasis faces::
|
||
* Update Org block delimiter fontification::
|
||
* Measure color contrast::
|
||
* Load theme depending on time of day::
|
||
* Backdrop for pdf-tools::
|
||
* Toggle themes without reloading them::
|
||
* A theme-agnostic hook for theme loading::
|
||
* Use more spacious margins or padding in Emacs frames::
|
||
* Custom hl-todo colors::
|
||
* Add support for solaire-mode::
|
||
|
||
|
||
File: modus-themes.info, Node: Palette override presets, Next: Stylistic variants using palette overrides, Up: Advanced customization
|
||
|
||
5.1 Palette override presets
|
||
============================
|
||
|
||
This section shows how to refashion the themes by opting in to the
|
||
stylistic presets we provide. Those presets override the default color
|
||
mappings to amplify, tone down, or refashion the overall coloration of
|
||
the themes.
|
||
|
||
To make almost all aspects of the themes less intense, use this:
|
||
|
||
;; Always remember to reload the theme for changes to take effect!
|
||
(setq modus-themes-common-palette-overrides modus-themes-preset-overrides-faint)
|
||
|
||
With ‘modus-themes-preset-overrides-faint’ the grays are toned down,
|
||
gray backgrounds are removed from some contexts, and almost all accent
|
||
colors are desaturated. It makes the themes less attention-grabbing.
|
||
|
||
On the opposite end of the stylistic spectrum, we have this
|
||
|
||
;; Always remember to reload the theme for changes to take effect!
|
||
(setq modus-themes-common-palette-overrides modus-themes-preset-overrides-intense)
|
||
|
||
The ‘modus-themes-preset-overrides-intense’ makes many background
|
||
colors accented instead of gray and increases coloration in a number of
|
||
places. Colors stand out more and are made easier to spot.
|
||
|
||
For some stylistic variation try the “cooler” and “warmer” presets:
|
||
|
||
;; This:
|
||
(setq modus-themes-common-palette-overrides modus-themes-preset-overrides-cooler)
|
||
|
||
;; Or:
|
||
(setq modus-themes-common-palette-overrides modus-themes-preset-overrides-warmer)
|
||
|
||
Note that the user is not limited to those presets. The system of
|
||
overrides we provide makes it possible to tweak the value of each
|
||
individual named color and to change how values are assigned to semantic
|
||
color mappings (*note Option for palette overrides: Palette overrides.).
|
||
Subsequent sections provide examples (*note Stylistic variants using
|
||
palette overrides::).
|
||
|
||
It is also possible to use those presets as a basis and, for example,
|
||
add to them code from the subsequent sections of this manual. This is
|
||
the general idea (extra space for didactic purposes):
|
||
|
||
(setq modus-themes-common-palette-overrides
|
||
`(
|
||
;; From the section "Make the mode line borderless"
|
||
(border-mode-line-active unspecified)
|
||
(border-mode-line-inactive unspecified)
|
||
|
||
;; From the section "Make matching parenthesis more or less intense"
|
||
(bg-paren-match bg-magenta-intense)
|
||
(underline-paren-match fg-main)
|
||
|
||
;; And expand the preset here. Note that the ,@ works because
|
||
;; we use the backtick for this list, instead of a straight
|
||
;; quote.
|
||
,@modus-themes-preset-overrides-intense))
|
||
|
||
|
||
File: modus-themes.info, Node: Stylistic variants using palette overrides, Next: More accurate colors in terminal emulators, Prev: Palette override presets, Up: Advanced customization
|
||
|
||
5.2 Stylistic variants using palette overrides
|
||
==============================================
|
||
|
||
This section contains practical examples of overriding the palette of
|
||
the themes (*note Option for palette overrides: Palette overrides.).
|
||
Users can copy the code to their init file, evaluate it, and then
|
||
re-load the theme for changes to take effect. To apply overrides at
|
||
startup simply define them before the call that loads the theme.
|
||
Remember that we also provide presets that are easier to apply (*note
|
||
Palette override presets::).
|
||
|
||
* Menu:
|
||
|
||
* Make the mode line borderless::
|
||
* Make the active mode line colorful::
|
||
* Make the tab bar more or less colorful::
|
||
* Make the fringe invisible or another color::
|
||
* Make links use subtle or no underlines::
|
||
* Make prompts more or less colorful::
|
||
* Make completion matches more or less colorful::
|
||
* Make comments yellow and strings green::
|
||
* Make code syntax use the old alt-syntax style::
|
||
* Make use of alternative styles for code syntax::
|
||
* Make matching parenthesis more or less intense::
|
||
* Make box buttons more or less gray::
|
||
* Make TODO and DONE more or less intense::
|
||
* Make headings more or less colorful::
|
||
* Make Org agenda more or less colorful::
|
||
* Make inline code in prose use alternative styles::
|
||
* Make mail citations and headers more or less colorful::
|
||
* Make the region preserve text colors, plus other styles: Make the region preserve text colors plus other styles.
|
||
* Make mouse highlights more or less colorful::
|
||
* Make language underlines less colorful::
|
||
* Make line numbers use alternative styles::
|
||
* Make diffs use only a foreground::
|
||
* Make deuteranopia diffs red and blue instead of yellow and blue::
|
||
* Make the themes look like what the maintainer uses::
|
||
|
||
|
||
File: modus-themes.info, Node: Make the mode line borderless, Next: Make the active mode line colorful, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.1 Make the mode line borderless
|
||
-----------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
To hide the border around the active and inactive mode lines, we need to
|
||
set their color to that of the underlying background.
|
||
|
||
*note Make the active mode line colorful::.
|
||
|
||
*note Add padding to mode line::.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
;; Remove the border
|
||
(setq modus-themes-common-palette-overrides
|
||
'((border-mode-line-active unspecified)
|
||
(border-mode-line-inactive unspecified)))
|
||
|
||
;; Keep the border but make it the same color as the background of the
|
||
;; mode line (thus appearing borderless). The difference with the
|
||
;; above is that this version is a bit thicker because the border are
|
||
;; still there.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((border-mode-line-active bg-mode-line-active)
|
||
(border-mode-line-inactive bg-mode-line-inactive)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make the active mode line colorful, Next: Make the tab bar more or less colorful, Prev: Make the mode line borderless, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.2 Make the active mode line colorful
|
||
----------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
Here we show some snippets that apply different stylistic variants. Of
|
||
course, it is possible to use theme-specific overrides to, say, have a
|
||
blue mode line for ‘modus-operandi’ and a red one for ‘modus-vivendi’.
|
||
|
||
*note Make the mode line borderless::.
|
||
|
||
*note Add padding to mode line::.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
;; Blue background, neutral foreground, intense blue border
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-mode-line-active bg-blue-intense)
|
||
(fg-mode-line-active fg-main)
|
||
(border-mode-line-active blue-intense)))
|
||
|
||
;; Subtle blue background, neutral foreground, intense blue border
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-mode-line-active bg-blue-subtle)
|
||
(fg-mode-line-active fg-main)
|
||
(border-mode-line-active blue-intense)))
|
||
|
||
;; Subtle red background, red foreground, invisible border
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-mode-line-active bg-red-subtle)
|
||
(fg-mode-line-active red-warmer)
|
||
(border-mode-line-active bg-red-subtle)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make the tab bar more or less colorful, Next: Make the fringe invisible or another color, Prev: Make the active mode line colorful, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.3 Make the tab bar more or less colorful
|
||
--------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
Here we show how to affect the colors of the built-in ‘tab-bar-mode’ and
|
||
‘tab-line-mode’.
|
||
|
||
For consistent theme-wide results, consider changing the mode line,
|
||
fringes, and line numbers. These are shown in other sections of this
|
||
manual.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
|
||
;; Make the `tab-bar-mode' mode subtle while keepings its original
|
||
;; gray aesthetic.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-tab-bar bg-main)
|
||
(bg-tab-current bg-active)
|
||
(bg-tab-other bg-dim)))
|
||
|
||
;; Like the above, but the current tab has a colorful background and
|
||
;; the inactive tabs have a slightly more noticeable gray background.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-tab-bar bg-main)
|
||
(bg-tab-current bg-cyan-intense)
|
||
(bg-tab-other bg-inactive)))
|
||
|
||
;; Make the tabs colorful, using a monochromatic pattern (e.g. shades
|
||
;; of cyan).
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-tab-bar bg-cyan-nuanced)
|
||
(bg-tab-current bg-cyan-intense)
|
||
(bg-tab-other bg-cyan-subtle)))
|
||
|
||
;; Like the above, but with a dichromatic pattern (cyan and magenta).
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-tab-bar bg-cyan-nuanced)
|
||
(bg-tab-current bg-magenta-intense)
|
||
(bg-tab-other bg-cyan-subtle)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make the fringe invisible or another color, Next: Make links use subtle or no underlines, Prev: Make the tab bar more or less colorful, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.4 Make the fringe invisible or another color
|
||
------------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
Here we show how to make the fringe invisible or how to assign to it a
|
||
different color. The “fringe” is a small area to the right and left
|
||
side of the Emacs window which shows indicators such as for truncation
|
||
or continuation lines.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
;; Make the fringe invisible
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fringe unspecified)))
|
||
|
||
;; Make the fringe more intense
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fringe bg-active)))
|
||
|
||
;; Make the fringe colorful, but nuanced
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fringe bg-blue-nuanced)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make links use subtle or no underlines, Next: Make prompts more or less colorful, Prev: Make the fringe invisible or another color, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.5 Make links use subtle or no underlines
|
||
--------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
In this example, we showcase the special use of the ‘unspecified’ symbol
|
||
that underline mappings can read correctly.
|
||
|
||
;; Subtle underlines
|
||
(setq modus-themes-common-palette-overrides
|
||
'((underline-link border)
|
||
(underline-link-visited border)
|
||
(underline-link-symbolic border)))
|
||
|
||
;; No underlines
|
||
(setq modus-themes-common-palette-overrides
|
||
'((underline-link unspecified)
|
||
(underline-link-visited unspecified)
|
||
(underline-link-symbolic unspecified)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make prompts more or less colorful, Next: Make completion matches more or less colorful, Prev: Make links use subtle or no underlines, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.6 Make prompts more or less colorful
|
||
----------------------------------------
|
||
|
||
This section contains practical examples of overriding the palette of
|
||
the themes (*note Option for palette overrides: Palette overrides.). In
|
||
the following code block we show how to add or remove color from
|
||
prompts.
|
||
|
||
*note Option for command prompt styles: Command prompts.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
;; Keep the background unspecified (like the default), but use a faint
|
||
;; foreground color.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-prompt cyan-faint)
|
||
(bg-prompt unspecified)))
|
||
|
||
;; Add a nuanced background to prompts that complements their foreground.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-prompt cyan)
|
||
(bg-prompt bg-cyan-nuanced)))
|
||
|
||
;; Add a yellow background and adjust the foreground accordingly.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-prompt fg-main)
|
||
(bg-prompt bg-yellow-subtle))) ; try to replace "subtle" with "intense"
|
||
|
||
|
||
File: modus-themes.info, Node: Make completion matches more or less colorful, Next: Make comments yellow and strings green, Prev: Make prompts more or less colorful, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.7 Make completion matches more or less colorful
|
||
---------------------------------------------------
|
||
|
||
This section contains practical examples of overriding the palette of
|
||
the themes (*note Option for palette overrides: Palette overrides.).
|
||
Here we demonstrate how to activate background coloration for completion
|
||
matches. We show three different degrees of intensity.
|
||
|
||
*note Option for completion framework aesthetics: Completion UIs.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
;; Add a nuanced background color to completion matches, while keeping
|
||
;; their foreground intact (foregrounds do not need to be specified in
|
||
;; this case, but we do it for didactic purposes).
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-completion-match-0 blue)
|
||
(fg-completion-match-1 magenta-warmer)
|
||
(fg-completion-match-2 cyan)
|
||
(fg-completion-match-3 red)
|
||
(bg-completion-match-0 bg-blue-nuanced)
|
||
(bg-completion-match-1 bg-magenta-nuanced)
|
||
(bg-completion-match-2 bg-cyan-nuanced)
|
||
(bg-completion-match-3 bg-red-nuanced)))
|
||
|
||
;; Add intense background colors to completion matches and adjust the
|
||
;; foregrounds accordingly.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-completion-match-0 fg-main)
|
||
(fg-completion-match-1 fg-main)
|
||
(fg-completion-match-2 fg-main)
|
||
(fg-completion-match-3 fg-main)
|
||
(bg-completion-match-0 bg-blue-intense)
|
||
(bg-completion-match-1 bg-yellow-intense)
|
||
(bg-completion-match-2 bg-cyan-intense)
|
||
(bg-completion-match-3 bg-red-intense)))
|
||
|
||
;; Like the above, but with subtle backgrounds.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-completion-match-0 fg-main)
|
||
(fg-completion-match-1 fg-main)
|
||
(fg-completion-match-2 fg-main)
|
||
(fg-completion-match-3 fg-main)
|
||
(bg-completion-match-0 bg-blue-subtle)
|
||
(bg-completion-match-1 bg-yellow-subtle)
|
||
(bg-completion-match-2 bg-cyan-subtle)
|
||
(bg-completion-match-3 bg-red-subtle)))
|
||
|
||
Adding to the above, it is possible to, say, reduce the number of
|
||
colors to two:
|
||
|
||
;; No backgrounds (like the default) and just use two colors.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-completion-match-0 blue)
|
||
(fg-completion-match-1 yellow)
|
||
(fg-completion-match-2 blue)
|
||
(fg-completion-match-3 yellow)
|
||
(bg-completion-match-0 unspecified)
|
||
(bg-completion-match-1 unspecified)
|
||
(bg-completion-match-2 unspecified)
|
||
(bg-completion-match-3 unspecified)))
|
||
|
||
;; Again, a two-color style but this time with backgrounds
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-completion-match-0 blue)
|
||
(fg-completion-match-1 yellow)
|
||
(fg-completion-match-2 blue)
|
||
(fg-completion-match-3 yellow)
|
||
(bg-completion-match-0 bg-blue-nuanced)
|
||
(bg-completion-match-1 bg-yellow-nuanced)
|
||
(bg-completion-match-2 bg-blue-nuanced)
|
||
(bg-completion-match-3 bg-yellow-nuanced)))
|
||
|
||
The user can mix and match to their liking.
|
||
|
||
|
||
File: modus-themes.info, Node: Make comments yellow and strings green, Next: Make code syntax use the old alt-syntax style, Prev: Make completion matches more or less colorful, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.8 Make comments yellow and strings green
|
||
--------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
In previous versions of the themes, we provided an option for yellow-ish
|
||
comments and green-ish strings. For some users, those were still not
|
||
good enough, as the exact values were hardcoded. Here we show how to
|
||
reproduce the effect, but also how to tweak it to one’s liking.
|
||
|
||
*note Make code syntax use the old alt-syntax style::.
|
||
|
||
*note Make use of alternative styles for code syntax::.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
;; Yellow comments and green strings like older versions of the Modus
|
||
;; themes
|
||
(setq modus-themes-common-palette-overrides
|
||
'((comment yellow-cooler)
|
||
(string green-cooler)))
|
||
|
||
;; Faint yellow comments and a different shade of green for strings
|
||
(setq modus-themes-common-palette-overrides
|
||
'((comment yellow-faint)
|
||
(string green-warmer)))
|
||
|
||
;; Green comments and yellow strings, because now the user has the
|
||
;; freedom to do it
|
||
(setq modus-themes-common-palette-overrides
|
||
'((comment green)
|
||
(string yellow-cooler)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make code syntax use the old alt-syntax style, Next: Make use of alternative styles for code syntax, Prev: Make comments yellow and strings green, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.9 Make code syntax use the old alt-syntax style
|
||
---------------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
In this section we show how to reproduce what previous versions of the
|
||
Modus themes provided as a stylistic alternative for code syntax. The
|
||
upside of using overrides for this purpose is that we can tweak the
|
||
style to our liking, but first let’s start with its recreation:
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
|
||
;; The old "alt-syntax"
|
||
(setq modus-themes-common-palette-overrides
|
||
'((builtin magenta)
|
||
(comment fg-dim)
|
||
(constant magenta-cooler)
|
||
(docstring magenta-faint)
|
||
(docmarkup green-faint)
|
||
(fnname magenta-warmer)
|
||
(keyword cyan)
|
||
(preprocessor cyan-cooler)
|
||
(string red-cooler)
|
||
(type magenta-cooler)
|
||
(variable blue-warmer)
|
||
(rx-construct magenta-warmer)
|
||
(rx-backslash blue-cooler)))
|
||
|
||
The “alt-syntax” could optionally use green strings and yellow
|
||
comments (*note Make comments yellow and strings green::):
|
||
|
||
;; Same as above, but with yellow comments and green strings
|
||
(setq modus-themes-common-palette-overrides
|
||
'((builtin magenta)
|
||
(comment yellow-faint)
|
||
(constant magenta-cooler)
|
||
(docstring green-faint)
|
||
(docmarkup magenta-faint)
|
||
(fnname magenta-warmer)
|
||
(keyword cyan)
|
||
(preprocessor cyan-cooler)
|
||
(string green-cooler)
|
||
(type magenta-cooler)
|
||
(variable blue-warmer)
|
||
(rx-construct magenta-warmer)
|
||
(rx-backslash blue-cooler)))
|
||
|
||
The standard “alt-syntax” has red strings. As such, it is
|
||
interesting to experiment with faintly red colored comments:
|
||
|
||
;; Like the old "alt-syntax" but with faint red comments
|
||
(setq modus-themes-common-palette-overrides
|
||
'((builtin magenta)
|
||
(comment red-faint)
|
||
(constant magenta-cooler)
|
||
(docstring magenta-faint)
|
||
(docmarkup green-faint)
|
||
(fnname magenta-warmer)
|
||
(keyword cyan)
|
||
(preprocessor cyan-cooler)
|
||
(string red-cooler)
|
||
(type magenta-cooler)
|
||
(variable blue-warmer)
|
||
(rx-construct magenta-warmer)
|
||
(rx-backslash blue-cooler)))
|
||
|
||
The user can always mix and match styles to their liking.
|
||
|
||
*note Make use of alternative styles for code syntax::.
|
||
|
||
|
||
File: modus-themes.info, Node: Make use of alternative styles for code syntax, Next: Make matching parenthesis more or less intense, Prev: Make code syntax use the old alt-syntax style, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.10 Make use of alternative styles for code syntax
|
||
-----------------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
The idea here is to change how named colors are mapped to code syntax.
|
||
Each of the following snippets give the ‘modus-themes’ a different feel
|
||
while editing code.
|
||
|
||
Note that my ‘modus-themes’ and ‘ef-themes’ do not use the same
|
||
palettes, so some things are different. If you copy from the latter to
|
||
the former, double-check that the entries exist in the given Modus theme
|
||
palette.
|
||
|
||
*note Make comments yellow and strings green::.
|
||
|
||
*note Make code syntax use the old alt-syntax style::.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
|
||
;; Mimic `ef-night' theme (from my `ef-themes') for code syntax
|
||
;; highlighting, while still using the Modus colors (and other
|
||
;; mappings).
|
||
(setq modus-themes-common-palette-overrides
|
||
'((builtin green-cooler)
|
||
(comment yellow-faint)
|
||
(constant magenta-cooler)
|
||
(fnname cyan-cooler)
|
||
(keyword blue-warmer)
|
||
(preprocessor red-warmer)
|
||
(docstring cyan-faint)
|
||
(string blue-cooler)
|
||
(type magenta-cooler)
|
||
(variable cyan)))
|
||
|
||
;; Mimic `ef-summer' theme (from my `ef-themes') for code syntax
|
||
;; highlighting, while still using the Modus colors (and other
|
||
;; mappings).
|
||
(setq modus-themes-common-palette-overrides
|
||
'((builtin magenta)
|
||
(comment yellow-faint)
|
||
(constant red-cooler)
|
||
(fnname magenta-warmer)
|
||
(keyword magenta-cooler)
|
||
(preprocessor green-warmer)
|
||
(docstring cyan-faint)
|
||
(string yellow-warmer)
|
||
(type cyan-warmer)
|
||
(variable blue-warmer)))
|
||
|
||
;; Mimic `ef-bio' theme (from my `ef-themes') for code syntax
|
||
;; highlighting, while still using the Modus colors (and other
|
||
;; mappings).
|
||
(setq modus-themes-common-palette-overrides
|
||
'((builtin green)
|
||
(comment yellow-faint)
|
||
(constant blue)
|
||
(fnname green-warmer)
|
||
(keyword green-cooler)
|
||
(preprocessor green)
|
||
(docstring green-faint)
|
||
(string magenta-cooler)
|
||
(type cyan-warmer)
|
||
(variable blue-warmer)))
|
||
|
||
;; Mimic `ef-trio-light' theme (from my `ef-themes') for code syntax
|
||
;; highlighting, while still using the Modus colors (and other
|
||
;; mappings).
|
||
(setq modus-themes-common-palette-overrides
|
||
'((builtin magenta-cooler)
|
||
(comment yellow-faint)
|
||
(constant magenta-warmer)
|
||
(fnname blue-warmer)
|
||
(keyword magenta)
|
||
(preprocessor red-cooler)
|
||
(docstring magenta-faint)
|
||
(string green-cooler)
|
||
(type cyan-cooler)
|
||
(variable cyan-warmer)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make matching parenthesis more or less intense, Next: Make box buttons more or less gray, Prev: Make use of alternative styles for code syntax, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.11 Make matching parenthesis more or less intense
|
||
-----------------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
In this code block we show how to change the background of matching
|
||
delimiters when ‘show-paren-mode’ is enabled. We also demonstrate how
|
||
to enable underlines for those highlights.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
;; Change the background to a shade of magenta
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-paren-match bg-magenta-intense)))
|
||
|
||
;; Enable underlines by applying a color to them
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-paren-match bg-magenta-intense)
|
||
(underline-paren-match fg-main)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make box buttons more or less gray, Next: Make TODO and DONE more or less intense, Prev: Make matching parenthesis more or less intense, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.12 Make box buttons more or less gray
|
||
-----------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
By default, the boxed buttons that appear in ‘M-x customize’ and related
|
||
are distinct shades of gray. The following set of overrides removes the
|
||
gray from the active buttons and amplifies it for the inactive ones.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-button-active bg-main)
|
||
(fg-button-active fg-main)
|
||
(bg-button-inactive bg-inactive)
|
||
(fg-button-inactive "gray50")))
|
||
|
||
|
||
File: modus-themes.info, Node: Make TODO and DONE more or less intense, Next: Make headings more or less colorful, Prev: Make box buttons more or less gray, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.13 Make TODO and DONE more or less intense
|
||
----------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
Here we show how to affect just the ‘TODO’ and ‘DONE’ keywords that we
|
||
encounter in Org buffers. The idea is to make those pop out more or to
|
||
subdue them.
|
||
|
||
*note Make headings more or less colorful::.
|
||
|
||
*note Make inline code in prose use alternative styles::.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
;; Increase intensity
|
||
(setq modus-themes-common-palette-overrides
|
||
'((prose-done green-intense)
|
||
(prose-todo red-intense)))
|
||
|
||
;; Tone down intensity
|
||
(setq modus-themes-common-palette-overrides
|
||
'((prose-done green-faint) ; OR replace `green-faint' with `olive'
|
||
(prose-todo red-faint))) ; OR replace `red-faint' with `rust'
|
||
|
||
;; Keep TODO at its default (so no override for it), but make DONE
|
||
;; gray.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((prose-done fg-dim)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make headings more or less colorful, Next: Make Org agenda more or less colorful, Prev: Make TODO and DONE more or less intense, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.14 Make headings more or less colorful
|
||
------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
Here we show how to alter the looks of headings, such as in Org mode.
|
||
Using overrides here offers far more flexibility than what we could
|
||
achieve with previous versions of the themes: the user can mix and match
|
||
styles at will.
|
||
|
||
*note Make TODO and DONE more intense: Make TODO and DONE more or
|
||
less intense.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
|
||
;; Apply more colorful foreground to some headings (headings 0-8).
|
||
;; Level 0 is for Org #+title and related.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-heading-1 blue-warmer)
|
||
(fg-heading-2 yellow-cooler)
|
||
(fg-heading-3 cyan-cooler)))
|
||
|
||
;; Like the above, but with gradient colors
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-heading-1 blue)
|
||
(fg-heading-2 cyan)
|
||
(fg-heading-3 green)))
|
||
|
||
;; Add color to level 1 heading, but use the main foreground for
|
||
;; others
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-heading-1 blue)
|
||
(fg-heading-2 fg-main)
|
||
(fg-heading-3 fg-main)))
|
||
|
||
;; Apply colorful foreground, background, and overline (headings 0-8)
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-heading-1 blue-warmer)
|
||
(bg-heading-1 bg-blue-nuanced)
|
||
(overline-heading-1 blue)))
|
||
|
||
;; Apply gray scale foreground, background, and overline (headings 0-8)
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-heading-1 fg-main)
|
||
(bg-heading-1 bg-dim)
|
||
(overline-heading-1 border)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make Org agenda more or less colorful, Next: Make inline code in prose use alternative styles, Prev: Make headings more or less colorful, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.15 Make Org agenda more or less colorful
|
||
--------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
Here we provide three distinct code blocks. The first adds alternative
|
||
and more varied colors to the Org agenda (and related). The second uses
|
||
faint coloration. The third makes the agenda use various shades of
|
||
blue. Mix and match at will, while also combining these styles with
|
||
what we show in the other chapters with practical stylistic variants.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
;; Make the Org agenda use alternative and varied colors.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((date-common cyan) ; default value (for timestamps and more)
|
||
(date-deadline red-warmer)
|
||
(date-event magenta-warmer)
|
||
(date-holiday blue) ; for M-x calendar
|
||
(date-now yellow-warmer)
|
||
(date-scheduled magenta-cooler)
|
||
(date-weekday cyan-cooler)
|
||
(date-weekend blue-faint)))
|
||
|
||
An example with faint coloration:
|
||
|
||
;; Make the Org agenda use faint colors.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((date-common cyan-faint) ; for timestamps and more
|
||
(date-deadline red-faint)
|
||
(date-event fg-alt) ; default
|
||
(date-holiday magenta) ; default (for M-x calendar)
|
||
(date-now fg-main) ; default
|
||
(date-scheduled yellow-faint)
|
||
(date-weekday fg-dim)
|
||
(date-weekend fg-dim)))
|
||
|
||
A third example that makes the agenda more blue:
|
||
|
||
;; Make the Org agenda use more blue instead of yellow and red.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((date-common cyan) ; default value (for timestamps and more)
|
||
(date-deadline blue-cooler)
|
||
(date-event blue-faint)
|
||
(date-holiday blue) ; for M-x calendar
|
||
(date-now blue-faint)
|
||
(date-scheduled blue)
|
||
(date-weekday fg-main)
|
||
(date-weekend fg-dim)))
|
||
|
||
Yet another example that also affects ‘DONE’ and ‘TODO’ keywords:
|
||
|
||
;; Change dates to a set of more subtle combinations. Deadlines are a
|
||
;; shade of magenta, scheduled dates are a shade of green that
|
||
;; complements that of the deadlines, weekday headings use the main
|
||
;; foreground color while weekends are a shade of gray. The DONE
|
||
;; keyword is a faint blue-gray while TODO is yellow.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((date-deadline magenta-warmer)
|
||
(date-scheduled green-cooler)
|
||
(date-weekday fg-main)
|
||
(date-event fg-dim)
|
||
(date-now blue)
|
||
(prose-done fg-alt)
|
||
(prose-todo yellow)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make inline code in prose use alternative styles, Next: Make mail citations and headers more or less colorful, Prev: Make Org agenda more or less colorful, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.16 Make inline code in prose use alternative styles
|
||
-------------------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
In the following code block we show how to affect constructs such as
|
||
Org’s verbatim, code, and macro entries. We also provide mappings for
|
||
tables, property drawers, tags, and code block delimiters, though we do
|
||
not show every possible permutation.
|
||
|
||
*note Make TODO and DONE more or less intense::.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
|
||
;; These are all the mappings at their default values for didactic
|
||
;; purposes
|
||
(setq modus-themes-common-palette-overrides
|
||
'((prose-block fg-dim)
|
||
(prose-code green-cooler)
|
||
(prose-done green)
|
||
(prose-macro magenta-cooler)
|
||
(prose-metadata fg-dim)
|
||
(prose-metadata-value fg-alt)
|
||
(prose-table fg-alt)
|
||
(prose-tag magenta-faint)
|
||
(prose-todo red)
|
||
(prose-verbatim magenta-warmer)))
|
||
|
||
;; Make code block delimiters use a shade of red, tone down verbatim,
|
||
;; code, and macro, and amplify the style of property drawers
|
||
(setq modus-themes-common-palette-overrides
|
||
'((prose-block red-faint)
|
||
(prose-code fg-dim)
|
||
(prose-macro magenta-faint)
|
||
(prose-metadata cyan)
|
||
(prose-metadata-value green-warmer)
|
||
(prose-verbatim fg-dim)))
|
||
|
||
;; Like the above but with more color variety for the inline code
|
||
;; elements
|
||
(setq modus-themes-common-palette-overrides
|
||
'((prose-block red-faint)
|
||
(prose-code blue-cooler)
|
||
(prose-macro yellow-warmer)
|
||
(prose-metadata cyan)
|
||
(prose-metadata-value green-warmer)
|
||
(prose-verbatim red-warmer)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make mail citations and headers more or less colorful, Next: Make the region preserve text colors plus other styles, Prev: Make inline code in prose use alternative styles, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.17 Make mail citations and headers more or less colorful
|
||
------------------------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
In this section we show how to change the coloration of email message
|
||
headers and citations. Before we show the code, this is the anatomy of
|
||
a message:
|
||
|
||
From: Protesilaos <info@protesilaos.com>
|
||
To: Modus-Themes Development <~protesilaos/modus-themes@lists.sr.ht>
|
||
Subject: Test subject
|
||
--- Headers above this line; message and citations below ---
|
||
This is some sample text
|
||
|
||
> > Older quote
|
||
> Newer quote
|
||
|
||
We thus have the following:
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
|
||
;; Reduce the intensity of mail citations and headers
|
||
(setq modus-themes-common-palette-overrides
|
||
'((mail-cite-0 cyan-faint)
|
||
(mail-cite-1 yellow-faint)
|
||
(mail-cite-2 green-faint)
|
||
(mail-cite-3 red-faint)
|
||
(mail-part olive)
|
||
(mail-recipient indigo)
|
||
(mail-subject maroon)
|
||
(mail-other slate)))
|
||
|
||
;; Make mail citations more intense; adjust the headers accordingly
|
||
(setq modus-themes-common-palette-overrides
|
||
'((mail-cite-0 blue)
|
||
(mail-cite-1 yellow)
|
||
(mail-cite-2 green)
|
||
(mail-cite-3 magenta)
|
||
(mail-part magenta-cooler)
|
||
(mail-recipient cyan)
|
||
(mail-subject red-warmer)
|
||
(mail-other cyan-cooler)))
|
||
|
||
;; Make all citations faint and neutral; make most headers green but
|
||
;; use red for the subject lie so that it stands out
|
||
(setq modus-themes-common-palette-overrides
|
||
'((mail-cite-0 fg-dim)
|
||
(mail-cite-1 fg-alt)
|
||
(mail-cite-2 fg-dim)
|
||
(mail-cite-3 fg-alt)
|
||
(mail-part yellow-cooler)
|
||
(mail-recipient green-cooler)
|
||
(mail-subject red-cooler)
|
||
(mail-other green)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make the region preserve text colors plus other styles, Next: Make mouse highlights more or less colorful, Prev: Make mail citations and headers more or less colorful, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.18 Make the region preserve text colors, plus other styles
|
||
--------------------------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
Here we show how to make the region respect the underlying text colors
|
||
or how to make the background more/less intense while combining it with
|
||
an appropriate foreground value.
|
||
|
||
*note Do not extend the region background::.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
|
||
;; A background with no specific foreground (use foreground of
|
||
;; underlying text)
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-region bg-ochre) ; try to replace `bg-ochre' with `bg-lavender', `bg-sage'
|
||
(fg-region unspecified)))
|
||
|
||
;; Subtle gray with a prominent blue foreground
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-region bg-dim)
|
||
(fg-region blue-cooler)))
|
||
|
||
;; Intense magenta background combined with the main foreground
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-region bg-magenta-intense)
|
||
(fg-region fg-main)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make mouse highlights more or less colorful, Next: Make language underlines less colorful, Prev: Make the region preserve text colors plus other styles, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.19 Make mouse highlights more or less colorful
|
||
--------------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
In the following code block we show how to affect the semantic color
|
||
mapping that covers mouse hover effects and related highlights:
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
|
||
;; Make the background an intense yellow
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-hover bg-yellow-intense)))
|
||
|
||
;; Make the background subtle green
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-hover bg-green-subtle)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make language underlines less colorful, Next: Make line numbers use alternative styles, Prev: Make mouse highlights more or less colorful, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.20 Make language underlines less colorful
|
||
---------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
Here we show how to affect the color of the underlines that are used by
|
||
code linters and prose spell checkers.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
|
||
;; Make the underlines less intense
|
||
(setq modus-themes-common-palette-overrides
|
||
'((underline-err red-faint)
|
||
(underline-warning yellow-faint)
|
||
(underline-note cyan-faint)))
|
||
|
||
;; Change the color-coding of the underlines
|
||
(setq modus-themes-common-palette-overrides
|
||
'((underline-err yellow-intense)
|
||
(underline-warning magenta-intense)
|
||
(underline-note green-intense)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make line numbers use alternative styles, Next: Make diffs use only a foreground, Prev: Make language underlines less colorful, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.21 Make line numbers use alternative styles
|
||
-----------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
In this section we show how to affect the ‘display-line-numbers-mode’.
|
||
|
||
;; These overrides are common to all Modus themes. We also provide
|
||
;; theme-specific options, such as `modus-operandi-palette-overrides'.
|
||
;;
|
||
;; In general, the theme-specific overrides are better for overriding
|
||
;; color values, such as redefining what `blue-faint' looks like. The
|
||
;; common overrides are best used for changes to semantic color
|
||
;; mappings, as we show below.
|
||
|
||
|
||
;; Make line numbers less intense
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-line-number-inactive "gray50")
|
||
(fg-line-number-active fg-main)
|
||
(bg-line-number-inactive unspecified)
|
||
(bg-line-number-active unspecified)))
|
||
|
||
;; Like the above, but use a shade of red for the current line number
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-line-number-inactive "gray50")
|
||
(fg-line-number-active red-cooler)
|
||
(bg-line-number-inactive unspecified)
|
||
(bg-line-number-active unspecified)))
|
||
|
||
;; Make all numbers more intense, use a more pronounce gray
|
||
;; background, and make the current line have a colored background
|
||
(setq modus-themes-common-palette-overrides
|
||
'((fg-line-number-inactive fg-main)
|
||
(fg-line-number-active fg-main)
|
||
(bg-line-number-inactive bg-inactive)
|
||
(bg-line-number-active bg-cyan-intense)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make diffs use only a foreground, Next: Make deuteranopia diffs red and blue instead of yellow and blue, Prev: Make line numbers use alternative styles, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.22 Make diffs use only a foreground
|
||
---------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
In this section we show how to change diff buffers (e.g. in ‘magit’) to
|
||
only use color-coded text without any added background. What we
|
||
basically do is to disable the applicable backgrounds and then intensify
|
||
the foregrounds. Since the deuteranopia-optimized themes do not use the
|
||
red-green color coding, we make an extra set of adjustments for them by
|
||
overriding their palettes directly instead of just using the “common”
|
||
overrides.
|
||
|
||
;; Diffs with only foreground colors. Word-wise ("refined") diffs
|
||
;; have a gray background to draw attention to themselves.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((bg-added unspecified)
|
||
(bg-added-faint unspecified)
|
||
(bg-added-refine bg-inactive)
|
||
(fg-added green)
|
||
(fg-added-intense green-intense)
|
||
|
||
(bg-changed unspecified)
|
||
(bg-changed-faint unspecified)
|
||
(bg-changed-refine bg-inactive)
|
||
(fg-changed yellow)
|
||
(fg-changed-intense yellow-intense)
|
||
|
||
(bg-removed unspecified)
|
||
(bg-removed-faint unspecified)
|
||
(bg-removed-refine bg-inactive)
|
||
(fg-removed red)
|
||
(fg-removed-intense red-intense)
|
||
|
||
(bg-diff-context unspecified)))
|
||
|
||
;; Because deuteranopia cannot use the typical red-yellow-green
|
||
;; combination, we need to arrange for a yellow-purple-blue sequence.
|
||
;; Notice that the above covers the "common" overrides, so we do not
|
||
;; need to reproduce the whole list of them.
|
||
(setq modus-operandi-deuteranopia-palette-overrides
|
||
'((fg-added blue)
|
||
(fg-added-intense blue-intense)
|
||
|
||
(fg-changed magenta-cooler)
|
||
(fg-changed-intense magenta-intense)
|
||
|
||
(fg-removed yellow-warmer)
|
||
(fg-removed-intense yellow-intense)))
|
||
|
||
(setq modus-vivendi-deuteranopia-palette-overrides
|
||
'((fg-added blue)
|
||
(fg-added-intense blue-intense)
|
||
|
||
(fg-changed magenta-cooler)
|
||
(fg-changed-intense magenta-intense)
|
||
|
||
(fg-removed yellow)
|
||
(fg-removed-intense yellow-intense)))
|
||
|
||
|
||
File: modus-themes.info, Node: Make deuteranopia diffs red and blue instead of yellow and blue, Next: Make the themes look like what the maintainer uses, Prev: Make diffs use only a foreground, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.23 Make deuteranopia diffs red and blue instead of yellow and blue
|
||
----------------------------------------------------------------------
|
||
|
||
This is one of our practical examples to override the semantic colors of
|
||
the Modus themes (*note Stylistic variants using palette overrides::).
|
||
In this section we show how to implement a red+blue color coding for
|
||
diffs in the themes ‘modus-operandi-deuteranopia’ and
|
||
‘modus-vivendi-deuteranopia’. As those themes are optimized for users
|
||
with red-green color deficiency, they do not use the typical red+green
|
||
color coding for diffs, defaulting instead to yellow+blue which are
|
||
discernible. Users with deuteranomaly or, generally, those who like a
|
||
different aesthetic, can use the following to make diffs use the
|
||
red+yellow+blue color coding for removed, changed, and added lines
|
||
respectively. This is achieved by overriding the “changed” and
|
||
“removed” entries to use the colors of regular ‘modus-operandi’ and
|
||
‘modus-vivendi’.
|
||
|
||
(setq modus-operandi-deuteranopia-palette-overrides
|
||
'((bg-changed "#ffdfa9")
|
||
(bg-changed-faint "#ffefbf")
|
||
(bg-changed-refine "#fac090")
|
||
(bg-changed-fringe "#d7c20a")
|
||
(fg-changed "#553d00")
|
||
(fg-changed-intense "#655000")
|
||
|
||
(bg-removed "#ffd8d5")
|
||
(bg-removed-faint "#ffe9e9")
|
||
(bg-removed-refine "#f3b5af")
|
||
(bg-removed-fringe "#d84a4f")
|
||
(fg-removed "#8f1313")
|
||
(fg-removed-intense "#aa2222")))
|
||
|
||
(setq modus-vivendi-deuteranopia-palette-overrides
|
||
'((bg-changed "#363300")
|
||
(bg-changed-faint "#2a1f00")
|
||
(bg-changed-refine "#4a4a00")
|
||
(bg-changed-fringe "#8a7a00")
|
||
(fg-changed "#efef80")
|
||
(fg-changed-intense "#c0b05f")
|
||
|
||
(bg-removed "#4f1119")
|
||
(bg-removed-faint "#380a0f")
|
||
(bg-removed-refine "#781a1f")
|
||
(bg-removed-fringe "#b81a1f")
|
||
(fg-removed "#ffbfbf")
|
||
(fg-removed-intense "#ff9095")))
|
||
|
||
|
||
File: modus-themes.info, Node: Make the themes look like what the maintainer uses, Prev: Make deuteranopia diffs red and blue instead of yellow and blue, Up: Stylistic variants using palette overrides
|
||
|
||
5.2.24 Make the themes look like what the maintainer uses
|
||
---------------------------------------------------------
|
||
|
||
Based on what we have learnt from the previous sections of this manual,
|
||
here is what Protesilaos uses:
|
||
|
||
;; Always reload the theme for changes to take effect!
|
||
|
||
(setq modus-themes-custom-auto-reload nil
|
||
modus-themes-to-toggle '(modus-operandi modus-vivendi)
|
||
modus-themes-mixed-fonts t
|
||
modus-themes-variable-pitch-ui nil
|
||
modus-themes-italic-constructs t
|
||
modus-themes-bold-constructs nil
|
||
modus-themes-org-blocks nil
|
||
modus-themes-completions '((t . (extrabold)))
|
||
modus-themes-prompts nil
|
||
modus-themes-headings
|
||
'((agenda-structure . (variable-pitch light 2.2))
|
||
(agenda-date . (variable-pitch regular 1.3))
|
||
(t . (regular 1.15))))
|
||
|
||
(setq modus-themes-common-palette-overrides
|
||
'((cursor magenta-cooler)
|
||
;; Make the fringe invisible.
|
||
(fringe unspecified)
|
||
;; Make line numbers less intense and add a shade of cyan
|
||
;; for the current line number.
|
||
(fg-line-number-inactive "gray50")
|
||
(fg-line-number-active cyan-cooler)
|
||
(bg-line-number-inactive unspecified)
|
||
(bg-line-number-active unspecified)
|
||
;; Make the current line of `hl-line-mode' a fine shade of
|
||
;; gray (though also see my `lin' package).
|
||
(bg-hl-line bg-dim)
|
||
;; Make the region have a cyan-green background with no
|
||
;; specific foreground (use foreground of underlying text).
|
||
;; "bg-sage" refers to Salvia officinalis, else the common
|
||
;; sage.
|
||
(bg-region bg-sage)
|
||
(fg-region unspecified)
|
||
;; Make matching parentheses a shade of magenta. It
|
||
;; complements the region nicely.
|
||
(bg-paren-match bg-magenta-intense)
|
||
;; Make email citations faint and neutral, reducing the
|
||
;; default four colors to two; make mail headers cyan-blue.
|
||
(mail-cite-0 fg-dim)
|
||
(mail-cite-1 blue-faint)
|
||
(mail-cite-2 fg-dim)
|
||
(mail-cite-3 blue-faint)
|
||
(mail-part cyan-warmer)
|
||
(mail-recipient blue-warmer)
|
||
(mail-subject magenta-cooler)
|
||
(mail-other cyan-warmer)
|
||
;; Change dates to a set of more subtle combinations.
|
||
(date-deadline magenta-cooler)
|
||
(date-scheduled magenta)
|
||
(date-weekday fg-main)
|
||
(date-event fg-dim)
|
||
(date-now blue-faint)
|
||
;; Make tags (Org) less colorful and tables look the same as
|
||
;; the default foreground.
|
||
(prose-done cyan-cooler)
|
||
(prose-tag fg-dim)
|
||
(prose-table fg-main)
|
||
;; Make headings less colorful (though I never use deeply
|
||
;; nested headings).
|
||
(fg-heading-2 blue-faint)
|
||
(fg-heading-3 magenta-faint)
|
||
(fg-heading-4 blue-faint)
|
||
(fg-heading-5 magenta-faint)
|
||
(fg-heading-6 blue-faint)
|
||
(fg-heading-7 magenta-faint)
|
||
(fg-heading-8 blue-faint)
|
||
;; Make the active mode line a fine shade of lavender
|
||
;; (purple) and tone down the gray of the inactive mode
|
||
;; lines.
|
||
(bg-mode-line-active bg-lavender)
|
||
(border-mode-line-active bg-lavender)
|
||
|
||
(bg-mode-line-inactive bg-dim)
|
||
(border-mode-line-inactive bg-inactive)
|
||
;; Make the prompts a shade of magenta, to fit in nicely with
|
||
;; the overall blue-cyan-purple style of the other overrides.
|
||
;; Add a nuanced background as well.
|
||
(bg-prompt bg-magenta-nuanced)
|
||
(fg-prompt magenta-cooler)
|
||
;; Tweak some more constructs for stylistic constistency.
|
||
(name blue-warmer)
|
||
(identifier magenta-faint)
|
||
(keybind magenta-cooler)
|
||
(accent-0 magenta-cooler)
|
||
(accent-1 cyan-cooler)
|
||
(accent-2 blue-warmer)
|
||
(accent-3 red-cooler)))
|
||
|
||
;; Make the active mode line have a pseudo 3D effect (this assumes
|
||
;; you are using the default mode line and not an extra package).
|
||
(custom-set-faces
|
||
'(mode-line ((t :box (:style released-button)))))
|
||
|
||
|
||
File: modus-themes.info, Node: More accurate colors in terminal emulators, Next: Range of color with terminal emulators, Prev: Stylistic variants using palette overrides, Up: Advanced customization
|
||
|
||
5.3 More accurate colors in terminal emulators
|
||
==============================================
|
||
|
||
[ This is based on partial information. Please help verify and/or
|
||
expand these findings. ]
|
||
|
||
The graphical version of Emacs can reproduce color values accurately.
|
||
Whereas things get more tricky when Emacs is used in a terminal
|
||
emulator, because the terminals’ own capabilities determine the number
|
||
of colors that may be displayed: the Modus themes don’t look as good in
|
||
that case.
|
||
|
||
There is, however, a way to instruct supported terminal emulators to
|
||
use more accurate colors. In a shell prompt type ‘toe -a | grep direct’
|
||
to get a list of relevant terminfo entries. There should be items such
|
||
as ‘xterm-direct’, ‘alacritty-direct’, ‘kitty-direct’. Once you find
|
||
the one that corresponds to your terminal, call Emacs with an
|
||
environment variable like ‘TERM=xterm-direct’. Example that can be
|
||
adapted to shell aliases:
|
||
|
||
TERM=xterm-direct emacsclient -nw
|
||
|
||
Another example that can be bound to a key:
|
||
|
||
TERM=xterm-direct uxterm -e emacsclient -nw
|
||
|
||
|
||
File: modus-themes.info, Node: Range of color with terminal emulators, Next: Preview theme colors, Prev: More accurate colors in terminal emulators, Up: Advanced customization
|
||
|
||
5.4 Range of color with terminal emulators
|
||
==========================================
|
||
|
||
[ This is based on partial information. Please help verify and/or
|
||
expand these findings. ]
|
||
|
||
When Emacs runs in a non-windowed session its color reproduction
|
||
capacity is framed or determined by the underlying terminal emulator
|
||
(*note More accurate colors in terminal emulators::). Emacs cannot
|
||
produce a color that lies outside the range of what the terminal’s color
|
||
palette renders possible.
|
||
|
||
This is immediately noticeable when the terminal’s first 16 codes do
|
||
not include a pure black value for the ‘termcol0’ entry and a pure white
|
||
for ‘termcol15’. Emacs cannot set the correct background (white for
|
||
‘modus-operandi’; black for ‘modus-vivendi’) or foreground (inverse of
|
||
the background). It thus falls back to the closest approximation, which
|
||
seldom is appropriate for the purposes of the Modus themes.
|
||
|
||
In such a case, the user is expected to update their terminal’s color
|
||
palette such as by adapting these resources (*note Preview theme
|
||
colors::):
|
||
|
||
! Theme: modus-operandi
|
||
! Description: XTerm port of modus-operandi (Modus themes for GNU Emacs)
|
||
! Author: Protesilaos Stavrou, <https://protesilaos.com>
|
||
xterm*background: #ffffff
|
||
xterm*foreground: #000000
|
||
xterm*color0: #000000
|
||
xterm*color1: #a60000
|
||
xterm*color2: #005e00
|
||
xterm*color3: #813e00
|
||
xterm*color4: #0031a9
|
||
xterm*color5: #721045
|
||
xterm*color6: #00538b
|
||
xterm*color7: #bfbfbf
|
||
xterm*color8: #595959
|
||
xterm*color9: #972500
|
||
xterm*color10: #315b00
|
||
xterm*color11: #70480f
|
||
xterm*color12: #2544bb
|
||
xterm*color13: #5317ac
|
||
xterm*color14: #005a5f
|
||
xterm*color15: #ffffff
|
||
|
||
! Theme: modus-vivendi
|
||
! Description: XTerm port of modus-vivendi (Modus themes for GNU Emacs)
|
||
! Author: Protesilaos Stavrou, <https://protesilaos.com>
|
||
xterm*background: #000000
|
||
xterm*foreground: #ffffff
|
||
xterm*color0: #000000
|
||
xterm*color1: #ff8059
|
||
xterm*color2: #44bc44
|
||
xterm*color3: #d0bc00
|
||
xterm*color4: #2fafff
|
||
xterm*color5: #feacd0
|
||
xterm*color6: #00d3d0
|
||
xterm*color7: #bfbfbf
|
||
xterm*color8: #595959
|
||
xterm*color9: #ef8b50
|
||
xterm*color10: #70b900
|
||
xterm*color11: #c0c530
|
||
xterm*color12: #79a8ff
|
||
xterm*color13: #b6a0ff
|
||
xterm*color14: #6ae4b9
|
||
xterm*color15: #ffffff
|
||
|
||
|
||
File: modus-themes.info, Node: Preview theme colors, Next: Per-theme customization settings, Prev: Range of color with terminal emulators, Up: Advanced customization
|
||
|
||
5.5 Preview theme colors
|
||
========================
|
||
|
||
The command ‘modus-themes-list-colors’ uses minibuffer completion to
|
||
select an item from the Modus themes and then produces a buffer with
|
||
previews of its color palette entries. The buffer has a naming scheme
|
||
that reflects the given choice, like ‘modus-operandi-list-colors’ for
|
||
the ‘modus-operandi’ theme.
|
||
|
||
The command ‘modus-themes-list-colors-current’ skips the minibuffer
|
||
selection process and just produces a preview for the current Modus
|
||
theme.
|
||
|
||
When called with a prefix argument (‘C-u’ with the default key
|
||
bindings), these commands will show a preview of the palette’s semantic
|
||
color mappings instead of the named colors. In this context, “named
|
||
colors” are entries that associate a symbol to a string color value,
|
||
such as ‘(blue-warmer "#354fcf")’. Whereas “semantic color mappings”
|
||
associate a named color to a symbol, like ‘(string blue-warmer)’, thus
|
||
making the theme render all string constructs in the ‘blue-warmer’ color
|
||
value (*note Option for palette overrides: Palette overrides.).
|
||
|
||
Aliases for those commands are ‘modus-themes-preview-colors’ and
|
||
‘modus-themes-preview-colors-current’.
|
||
|
||
Each row shows a foreground and background coloration using the
|
||
underlying value it references. For example a line with ‘#a60000’ (a
|
||
shade of red) will show red text followed by a stripe with that same
|
||
color as a backdrop.
|
||
|
||
The name of the buffer describes the given Modus theme and what the
|
||
contents are, such as ‘*modus-operandi-list-colors*’ for named colors
|
||
and ‘=*modus-operandi-list-mappings*’ for the semantic color mappings.
|
||
|
||
|
||
File: modus-themes.info, Node: Per-theme customization settings, Next: Get a single color from the palette, Prev: Preview theme colors, Up: Advanced customization
|
||
|
||
5.6 Per-theme customization settings
|
||
====================================
|
||
|
||
If you prefer to maintain different customization options between the
|
||
two themes, it is best you write your own functions that first set those
|
||
options and then load the relevant theme. The following code does
|
||
exactly that by simply differentiating the two themes on the choice of
|
||
bold constructs in code syntax (enabled for one, disabled for the
|
||
other).
|
||
|
||
(defun my-demo-modus-operandi ()
|
||
(interactive)
|
||
(setq modus-themes-bold-constructs t) ; ENABLE bold
|
||
(modus-themes-load-theme 'modus-operandi))
|
||
|
||
(defun my-demo-modus-vivendi ()
|
||
(interactive)
|
||
(setq modus-themes-bold-constructs nil) ; DISABLE bold
|
||
(modus-themes-load-theme 'modus-vivendi))
|
||
|
||
(defun my-demo-modus-themes-toggle ()
|
||
(if (eq (car custom-enabled-themes) 'modus-operandi)
|
||
(my-demo-modus-vivendi)
|
||
(my-demo-modus-operandi)))
|
||
|
||
Then assign ‘my-demo-modus-themes-toggle’ to a key instead of the
|
||
equivalent the themes provide.
|
||
|
||
For a more elaborate design, it is better to inspect the source code
|
||
of ‘modus-themes-toggle’ and relevant functions.
|
||
|
||
|
||
File: modus-themes.info, Node: Get a single color from the palette, Next: Use theme colors in code with modus-themes-with-colors, Prev: Per-theme customization settings, Up: Advanced customization
|
||
|
||
5.7 Get a single color from the palette
|
||
=======================================
|
||
|
||
*note Use theme colors in code with modus-themes-with-colors::.
|
||
|
||
The fuction ‘modus-themes-get-color-value’ can be called from Lisp to
|
||
return the value of a color from the active Modus theme palette. It
|
||
takea a ‘COLOR’ argument and an optional ‘OVERRIDES’.
|
||
|
||
‘COLOR’ is a symbol that represents a named color entry in the
|
||
palette.
|
||
|
||
*note Preview theme colors::.
|
||
|
||
If the value is the name of another color entry in the palette (so a
|
||
mapping), this function recurs until it finds the underlying color
|
||
value.
|
||
|
||
With an optional ‘OVERRIDES’ argument as a non-‘nil’ value, it
|
||
accounts for palette overrides. Else it reads only the default palette.
|
||
|
||
*note Option for palette overrides: Palette overrides.
|
||
|
||
With optional ‘THEME’ as a symbol among ‘modus-themes-items’ (alias
|
||
‘modus-themes-collection’), use the palette of that item. Else use the
|
||
current Modus theme.
|
||
|
||
If ‘COLOR’ is not present in the palette, this function returns the
|
||
‘unspecified’ symbol, which is safe when used as a face attribute’s
|
||
value.
|
||
|
||
An example with ‘modus-operandi’ to show how this function behaves
|
||
with/without overrides and when recursive mappings are introduced.
|
||
|
||
;; Here we show the recursion of palette mappings. In general, it is
|
||
;; better for the user to specify named colors to avoid possible
|
||
;; confusion with their configuration, though those still work as
|
||
;; expected.
|
||
(setq modus-themes-common-palette-overrides
|
||
'((cursor red)
|
||
(fg-mode-line-active cursor)
|
||
(border-mode-line-active fg-mode-line-active)))
|
||
|
||
;; Ignore the overrides and get the original value.
|
||
(modus-themes-get-color-value 'border-mode-line-active)
|
||
;; => "#5a5a5a"
|
||
|
||
;; Read from the overrides and deal with any recursion to find the
|
||
;; underlying value.
|
||
(modus-themes-get-color-value 'border-mode-line-active :overrides)
|
||
;; => "#a60000"
|
||
|
||
|
||
File: modus-themes.info, Node: Use theme colors in code with modus-themes-with-colors, Next: Do not extend the region background, Prev: Get a single color from the palette, Up: Advanced customization
|
||
|
||
5.8 Use theme colors in code with modus-themes-with-colors
|
||
==========================================================
|
||
|
||
*note Get a single color from the palette::.
|
||
|
||
Note that users most probably do not need the following. Just rely
|
||
on the comprehensive overrides we provide (*note Option for palette
|
||
overrides: Palette overrides.).
|
||
|
||
Advanced users may want to apply colors from the palette of the
|
||
active Modus theme in their custom code. The ‘modus-themes-with-colors’
|
||
macro supplies those to any form called inside of it. For example:
|
||
|
||
(modus-themes-with-colors
|
||
(list blue-warmer magenta-cooler fg-added warning variable fg-heading-4))
|
||
;; => ("#354fcf" "#531ab6" "#005000" "#884900" "#005e8b" "#721045")
|
||
|
||
The above return value is for ‘modus-operandi’ when that is the
|
||
active theme. Switching to another theme and evaluating this code anew
|
||
will give us the relevant results for that theme (remember that since
|
||
version 4, the Modus themes consist of six items (*note Overview::)).
|
||
The same with ‘modus-vivendi’ as the active theme:
|
||
|
||
(modus-themes-with-colors
|
||
(list blue-warmer magenta-cooler fg-added warning variable fg-heading-4))
|
||
;; => ("#79a8ff" "#b6a0ff" "#a0e0a0" "#fec43f" "#00d3d0" "#feacd0")
|
||
|
||
The ‘modus-themes-with-colors’ has access to the whole palette of the
|
||
active theme, meaning that it can instantiate both (i) named colors like
|
||
‘blue-warmer’ and (ii) semantic color mappings like ‘warning’. We
|
||
provide commands to inspect those (*note Preview theme colors::).
|
||
|
||
Others sections in this manual show how to use the aforementioned
|
||
macro (*note Advanced customization::).
|
||
|
||
Because the ‘modus-themes-with-colors’ will most likely be used to
|
||
customize faces, note that any function that calls it must be run at
|
||
startup after the theme loads. The same function must also be assigned
|
||
to the ‘modus-themes-after-load-theme-hook’ for its effects to persist
|
||
and be updated when switching between Modus themes (e.g. to update the
|
||
exact value of ‘blue-warmer’ when toggling between ‘modus-operandi’ to
|
||
‘modus-vivendi’.
|
||
|
||
|
||
File: modus-themes.info, Node: Do not extend the region background, Next: Add padding to mode line, Prev: Use theme colors in code with modus-themes-with-colors, Up: Advanced customization
|
||
|
||
5.9 Do not extend the region background
|
||
=======================================
|
||
|
||
By the default, the background of the ‘region’ face extends from the end
|
||
of the line to the edge of the window. To limit it to the end of the
|
||
line, we need to override the face’s ‘:extend’ attribute. Adding this
|
||
to the Emacs configuration file will suffice:
|
||
|
||
;; Do not extend `region' background past the end of the line.
|
||
(custom-set-faces
|
||
'(region ((t :extend nil))))
|
||
|
||
*note Make the region preserve text colors, plus other styles: Make
|
||
the region preserve text colors plus other styles.
|
||
|
||
|
||
File: modus-themes.info, Node: Add padding to mode line, Next: Remap face with local value, Prev: Do not extend the region background, Up: Advanced customization
|
||
|
||
5.10 Add padding to mode line
|
||
=============================
|
||
|
||
Emacs faces do not have a concept of “padding” for the space between the
|
||
text and its box boundaries. We can approximate the effect by adding a
|
||
‘:box’ attribute, making its border several pixels thick, and using the
|
||
mode line’s background color for it. This way the thick border will not
|
||
stand out and will appear as a continuation of the mode line.
|
||
|
||
*note Use theme colors in code with modus-themes-with-colors::.
|
||
|
||
(defun my-modus-themes-custom-faces ()
|
||
(modus-themes-with-colors
|
||
(custom-set-faces
|
||
;; Add "padding" to the mode lines
|
||
`(mode-line ((,c :box (:line-width 10 :color ,bg-mode-line-active))))
|
||
`(mode-line-inactive ((,c :box (:line-width 10 :color ,bg-mode-line-inactive)))))))
|
||
|
||
(add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-custom-faces)
|
||
|
||
The above has the effect of removing the border around the mode
|
||
lines. In older versions of the themes, we provided the option for a
|
||
padded mode line which could also have borders around it. Those were
|
||
not real border, however, but an underline and an overline. Adjusting
|
||
the above:
|
||
|
||
(defun my-modus-themes-custom-faces ()
|
||
(modus-themes-with-colors
|
||
(custom-set-faces
|
||
;; Add "padding" to the mode lines
|
||
`(mode-line ((,c :underline ,border-mode-line-active
|
||
:overline ,border-mode-line-active
|
||
:box (:line-width 10 :color ,bg-mode-line-active))))
|
||
`(mode-line-inactive ((,c :underline ,border-mode-line-inactive
|
||
:overline ,border-mode-line-inactive
|
||
:box (:line-width 10 :color ,bg-mode-line-inactive)))))))
|
||
|
||
;; ESSENTIAL to make the underline move to the bottom of the box:
|
||
(setq x-underline-at-descent-line t)
|
||
|
||
(add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-custom-faces)
|
||
|
||
The reason we no longer provide this option is because it depends on
|
||
a non-‘nil’ value for ‘x-underline-at-descent-line’. That variable
|
||
affects ALL underlines, including those of links. The effect is
|
||
intrusive and looks awkard in prose.
|
||
|
||
As such, the Modus themes no longer provide that option but instead
|
||
offer this piece of documentation to make the user fully aware of the
|
||
state of affairs.
|
||
|
||
|
||
File: modus-themes.info, Node: Remap face with local value, Next: Font configurations for Org and others, Prev: Add padding to mode line, Up: Advanced customization
|
||
|
||
5.11 Remap face with local value
|
||
================================
|
||
|
||
There are cases where we need to change the buffer-local attributes of a
|
||
face. This might be because we have our own minor mode that re-uses a
|
||
face for a particular purpose, such as a line selection tool that
|
||
activates ‘hl-line-mode’, but we wish to keep it distinct from other
|
||
buffers. This is where ‘face-remap-add-relative’ can be applied and may
|
||
be combined with ‘modus-themes-with-colors’ to deliver consistent
|
||
results.
|
||
|
||
*note Use theme colors in code with modus-themes-with-colors::.
|
||
|
||
In this example we will write a simple interactive function that
|
||
adjusts the background color of the ‘region’ face. This is the sample
|
||
code:
|
||
|
||
(defvar my-rainbow-region-colors
|
||
(modus-themes-with-colors
|
||
`((red . ,bg-red-subtle)
|
||
(green . ,bg-green-subtle)
|
||
(yellow . ,bg-yellow-subtle)
|
||
(blue . ,bg-blue-subtle)
|
||
(magenta . ,bg-magenta-subtle)
|
||
(cyan . ,bg-cyan-subtle)))
|
||
"Sample list of color values for `my-rainbow-region'.")
|
||
|
||
(defun my-rainbow-region (color)
|
||
"Remap buffer-local attribute of `region' using COLOR."
|
||
(interactive
|
||
(list
|
||
(completing-read "Pick a color: " my-rainbow-region-colors)))
|
||
(face-remap-add-relative
|
||
'region
|
||
`( :background ,(alist-get (intern color) my-rainbow-region-colors)
|
||
:foreground ,(face-attribute 'default :foreground))))
|
||
|
||
When ‘my-rainbow-region’ is called interactively, it prompts for a
|
||
color to use. The list of candidates is drawn from the car of each
|
||
association in ‘my-rainbow-region-colors’ (so “red”, “green”, etc.).
|
||
|
||
To extend this principle, we may write wrapper functions that pass a
|
||
color directly. Those can be useful in tandem with hooks. Consider
|
||
this example:
|
||
|
||
(defun my-rainbow-region-magenta ()
|
||
(my-rainbow-region 'magenta))
|
||
|
||
(add-hook 'diff-mode-hook #'my-rainbow-region-magenta)
|
||
|
||
Whenever we enter a ‘diff-mode’ buffer, we now get a magenta-colored
|
||
region.
|
||
|
||
Perhaps you may wish to generalize those findings in to a set of
|
||
functions that also accept an arbitrary face. We shall leave the
|
||
experimentation up to you.
|
||
|
||
|
||
File: modus-themes.info, Node: Font configurations for Org and others, Next: Configure bold and italic faces, Prev: Remap face with local value, Up: Advanced customization
|
||
|
||
5.12 Font configurations for Org and others
|
||
===========================================
|
||
|
||
The themes are designed to optionally cope well with mixed font
|
||
configurations. This mostly concerns ‘org-mode’ and ‘markdown-mode’,
|
||
though expect to find it elsewhere like in ‘Info-mode’.
|
||
|
||
*note Option for font mixing: Mixed fonts.
|
||
|
||
In practice it means that the user can safely opt for a more
|
||
prose-friendly proportionately spaced typeface as their default, while
|
||
spacing-sensitive elements like tables and inline code always use a
|
||
monospaced font, by inheriting from the ‘fixed-pitch’ face.
|
||
|
||
Users can try the built-in ‘M-x variable-pitch-mode’ to see the
|
||
effect in action.
|
||
|
||
To make everything use your desired font families, you need to
|
||
configure the ‘variable-pitch’ (proportional spacing) and ‘fixed-pitch’
|
||
(monospaced) faces respectively. It may also be convenient to set your
|
||
main typeface by configuring the ‘default’ face the same way.
|
||
|
||
[ The ‘fontaine’ package on GNU ELPA (by Protesilaos) is designed to
|
||
handle this case. ]
|
||
|
||
Put something like this in your initialization file (also consider
|
||
reading the doc string of ‘set-face-attribute’):
|
||
|
||
;; Main typeface
|
||
(set-face-attribute 'default nil :family "DejaVu Sans Mono" :height 110)
|
||
|
||
;; Proportionately spaced typeface
|
||
(set-face-attribute 'variable-pitch nil :family "DejaVu Serif" :height 1.0)
|
||
|
||
;; Monospaced typeface
|
||
(set-face-attribute 'fixed-pitch nil :family "DejaVu Sans Mono" :height 1.5)
|
||
|
||
Or employ the ‘face-attribute’ function to read an existing value,
|
||
such as if you want to make ‘fixed-pitch’ use the font family of the
|
||
‘default’ face:
|
||
|
||
(set-face-attribute 'fixed-pitch nil :family (face-attribute 'default :family))
|
||
|
||
The next section shows how to make those work in a more elaborate
|
||
setup that is robust to changes between the Modus themes.
|
||
|
||
*note Configure bold and italic faces::.
|
||
|
||
Note the differences in the ‘:height’ property. The ‘default’ face
|
||
must specify an absolute value, which is the point size × 10. So if you
|
||
want to use a font at point size ‘11’, you set the height to ‘110’.(1)
|
||
Whereas every other face must either not specify a height or have a
|
||
value that is relative to the default, represented as a floating point.
|
||
If you use an integer, then that means an absolute height. This is of
|
||
paramount importance: it ensures that all fonts can scale gracefully
|
||
when using something like the ‘text-scale-adjust’ command which only
|
||
operates on the base font size (i.e. the ‘default’ face’s absolute
|
||
height).
|
||
|
||
*note Note for EWW and Elfeed fonts: Note on SHR fonts.
|
||
|
||
---------- Footnotes ----------
|
||
|
||
(1) ‘:height’ values do not need to be rounded to multiples of ten:
|
||
the likes of ‘115’ are perfectly valid—some typefaces will change to
|
||
account for those finer increments.
|
||
|
||
|
||
File: modus-themes.info, Node: Configure bold and italic faces, Next: Custom Org todo keyword and priority faces, Prev: Font configurations for Org and others, Up: Advanced customization
|
||
|
||
5.13 Configure bold and italic faces
|
||
====================================
|
||
|
||
The Modus themes do not hardcode a ‘:weight’ or ‘:slant’ attribute in
|
||
the thousands of faces they cover. Instead, they configure the generic
|
||
faces called ‘bold’ and ‘italic’ to use the appropriate styles and then
|
||
instruct all relevant faces that require emphasis to inherit from them.
|
||
|
||
This practically means that users can change the particularities of
|
||
what it means for a construct to be bold/italic, by tweaking the ‘bold’
|
||
and ‘italic’ faces. Cases where that can be useful include:
|
||
|
||
• The default typeface does not have a variant with slanted glyphs
|
||
(e.g. Fira Mono/Code as of this writing on 2021-07-07), so the
|
||
user wants to add another family for the italics, such as Hack.
|
||
|
||
• The typeface of choice provides a multitude of weights and the user
|
||
prefers the light one by default. To prevent the bold weight from
|
||
being too heavy compared to the light one, they opt to make ‘bold’
|
||
use a semibold weight.
|
||
|
||
• The typeface distinguishes between oblique and italic forms by
|
||
providing different font variants (the former are just slanted
|
||
versions of the upright forms, while the latter have distinguishing
|
||
features as well). In this case, the user wants to specify the
|
||
font that applies to the ‘italic’ face.
|
||
|
||
To achieve those effects, one must first be sure that the fonts they
|
||
use have support for those features. It then is a matter of following
|
||
the instructions for all typeface tweaks.
|
||
|
||
*note Font configurations for Org and others::.
|
||
|
||
In this example, we set the default font family to Fira Code, while
|
||
we choose to render italics in the Hack typeface (obviously you need to
|
||
pick fonts that work well together):
|
||
|
||
(set-face-attribute 'default nil :family "Fira Code" :height 110)
|
||
(set-face-attribute 'italic nil :family "Hack")
|
||
|
||
And here we play with different weights, using Source Code Pro:
|
||
|
||
(set-face-attribute 'default nil :family "Source Code Pro" :height 110 :weight 'light)
|
||
(set-face-attribute 'bold nil :weight 'semibold)
|
||
|
||
To reset the font family, one can use this:
|
||
|
||
(set-face-attribute 'italic nil :family 'unspecified)
|
||
|
||
To ensure that the effects persist after switching between the Modus
|
||
themes (such as with ‘M-x modus-themes-toggle’), the user needs to write
|
||
their configurations to a function and pass it to the
|
||
‘modus-themes-after-load-theme-hook’. This is necessary because themes
|
||
set the styles of faces upon activation, overriding prior values where
|
||
conflicts occur between the previous and the current states (otherwise
|
||
changing themes would not be possible).
|
||
|
||
*note A theme-agnostic hook for theme loading::.
|
||
|
||
This is a minimal setup to preserve font configurations across theme
|
||
load phases. For a more permanent setup, it is better to rely on the
|
||
‘custom-set-faces’ function: ‘set-face-attribute’ works just fine,
|
||
though it probably is better suited for quick previews or for smaller
|
||
scale operations (‘custom-set-faces’ follows the format used in the
|
||
source code of the themes, which can make it easier to redefine faces in
|
||
bulk).
|
||
|
||
;; our generic function
|
||
(defun my-modes-themes-bold-italic-faces ()
|
||
(set-face-attribute 'default nil :family "Source Code Pro" :height 110)
|
||
(set-face-attribute 'bold nil :weight 'semibold))
|
||
|
||
;; or use this if you configure a lot of face and attributes and
|
||
;; especially if you plan to use `modus-themes-with-colors', as shown
|
||
;; elsewhere in the manual
|
||
(defun my-modes-themes-bold-italic-faces ()
|
||
(custom-set-faces
|
||
'(default ((t :family "Source Code Pro" :height 110)))
|
||
'(bold ((t :weight semibold)))))
|
||
|
||
;; and here is the hook
|
||
(add-hook 'modus-themes-after-load-theme-hook #'my-modes-themes-bold-italic-faces)
|
||
|
||
*note Use theme colors in code with modus-themes-with-colors::.
|
||
|
||
|
||
File: modus-themes.info, Node: Custom Org todo keyword and priority faces, Next: Custom Org emphasis faces, Prev: Configure bold and italic faces, Up: Advanced customization
|
||
|
||
5.14 Custom Org todo keyword and priority faces
|
||
===============================================
|
||
|
||
Users of ‘org-mode’ have the option to configure various keywords and
|
||
priority cookies to better match their workflow. User options are
|
||
‘org-todo-keyword-faces’ and ‘org-priority-faces’.
|
||
|
||
As those are meant to be custom faces, it is futile to have the
|
||
themes guess what each user wants to use, which keywords to target, and
|
||
so on. Instead, we can provide guidelines on how to customize things to
|
||
one’s liking with the intent of retaining the overall aesthetic of the
|
||
themes.
|
||
|
||
Please bear in mind that the end result of those is not controlled by
|
||
the active Modus theme but by how Org maps faces to its constructs.
|
||
Editing those while ‘org-mode’ is active requires re-initialization of
|
||
the mode with ‘M-x org-mode-restart’ for changes to take effect.
|
||
|
||
Let us assume you wish to visually differentiate your keywords. You
|
||
have something like this:
|
||
|
||
(setq org-todo-keywords
|
||
'((sequence "TODO(t)" "|" "DONE(D)" "CANCEL(C)")
|
||
(sequence "MEET(m)" "|" "MET(M)")
|
||
(sequence "STUDY(s)" "|" "STUDIED(S)")
|
||
(sequence "WRITE(w)" "|" "WROTE(W)")))
|
||
|
||
You could then use a variant of the following to inherit from a face
|
||
that uses the styles you want and also to preserve the attributes
|
||
applied by the ‘org-todo’ face (in case there is a difference between
|
||
the two):
|
||
|
||
(setq org-todo-keyword-faces
|
||
'(("MEET" . (:inherit (bold org-todo)))
|
||
("STUDY" . (:inherit (warning org-todo)))
|
||
("WRITE" . (:inherit (shadow org-todo)))))
|
||
|
||
This will refashion the keywords you specify, while letting the other
|
||
items in ‘org-todo-keywords’ use their original styles, which are
|
||
defined in the ‘org-todo’ and ‘org-done’ faces.
|
||
|
||
If you want back the defaults, try specifying just the ‘org-todo’
|
||
face:
|
||
|
||
(setq org-todo-keyword-faces
|
||
'(("MEET" . org-todo)
|
||
("STUDY" . org-todo)
|
||
("WRITE" . org-todo)))
|
||
|
||
Or set ‘org-todo-keyword-faces’ to ‘nil’.
|
||
|
||
When you inherit from multiple faces, you need to do it the way it is
|
||
shown further above. The order is significant: the first entry is
|
||
applied on top of the second, overriding any attributes that are
|
||
explicitly set for both of them: any attribute that is not specified is
|
||
not overridden, so, for example, if ‘org-todo’ has a background and a
|
||
foreground, while ‘font-lock-type-face’ only has a foreground, the
|
||
merged face will include the background of the former and the foreground
|
||
of the latter. If you do not want to blend multiple faces, you only
|
||
specify one by name without parentheses or an ‘:inherit’ keyword. A
|
||
pattern of ‘keyword . face’ will suffice.
|
||
|
||
Both approaches can be used simultaneously, as illustrated in this
|
||
configuration of the priority cookies:
|
||
|
||
(setq org-priority-faces
|
||
'((?A . (:inherit (bold org-priority)))
|
||
(?B . org-priority)
|
||
(?C . (:inherit (shadow org-priority)))))
|
||
|
||
To find all the faces that are loaded in your current Emacs session,
|
||
use ‘M-x list-faces-display’. Try ‘M-x describe-variable’ as well and
|
||
then specify the name of each of those Org variables demonstrated above.
|
||
Their documentation strings will offer you further guidance.
|
||
|
||
Recall that the themes let you retrieve a color from their palette.
|
||
Do it if you plan to control face attributes.
|
||
|
||
*note Check color combinations: Measure color contrast.
|
||
|
||
|
||
File: modus-themes.info, Node: Custom Org emphasis faces, Next: Update Org block delimiter fontification, Prev: Custom Org todo keyword and priority faces, Up: Advanced customization
|
||
|
||
5.15 Custom Org emphasis faces
|
||
==============================
|
||
|
||
Org provides the user option ‘org-emphasis-alist’ which associates a
|
||
character with a face, list of faces, or face attributes. The default
|
||
specification of that variable looks like this:
|
||
|
||
(setq org-emphasis-alist
|
||
'(("*" bold)
|
||
("/" italic)
|
||
("_" underline)
|
||
("=" org-verbatim verbatim)
|
||
("~" org-code verbatim)
|
||
("+" (:strike-through t))))
|
||
|
||
With the exception of ‘org-verbatim’ and ‘org-code’ faces, everything
|
||
else uses the corresponding type of emphasis: a bold typographic weight,
|
||
or italicised, underlined, and struck through text.
|
||
|
||
The best way for users to add some extra attributes, such as a
|
||
foreground color, is to define their own faces and assign them to the
|
||
given emphasis marker/character.
|
||
|
||
This is a custom face that extends the standard ‘bold’ face with a
|
||
red foreground value (so it colorises the text in addition to the bold
|
||
weight):
|
||
|
||
(defface my-org-emphasis-bold
|
||
'((default :inherit bold)
|
||
(((class color) (min-colors 88) (background light))
|
||
:foreground "#a60000")
|
||
(((class color) (min-colors 88) (background dark))
|
||
:foreground "#ff8059"))
|
||
"My bold emphasis for Org.")
|
||
|
||
This face definition reads as follows:
|
||
|
||
• Always inherit the ‘bold’ face (*note Configure bold and italic
|
||
faces::).
|
||
• For versions of Emacs that support at least 88 colors (graphical
|
||
Emacs, for example) and use a light background, apply the ‘#a60000’
|
||
value.
|
||
• For the same kind of Emacs that has a dark background use the
|
||
‘#ff8059’ color instead.
|
||
|
||
Same principle for how to extend ‘italic’ and ‘underline’ with, for
|
||
example, green and yellow hues, respectively:
|
||
|
||
(defface my-org-emphasis-italic
|
||
'((default :inherit italic)
|
||
(((class color) (min-colors 88) (background light))
|
||
:foreground "#005e00")
|
||
(((class color) (min-colors 88) (background dark))
|
||
:foreground "#44bc44"))
|
||
"My italic emphasis for Org.")
|
||
|
||
(defface my-org-emphasis-underline
|
||
'((default :inherit underline)
|
||
(((class color) (min-colors 88) (background light))
|
||
:foreground "#813e00")
|
||
(((class color) (min-colors 88) (background dark))
|
||
:foreground "#d0bc00"))
|
||
"My underline emphasis for Org.")
|
||
|
||
In the case of a strike-through effect, we have no generic face to
|
||
inherit from, so we can write it as follows to also change the
|
||
foreground to a more subtle gray:
|
||
|
||
(defface my-org-emphasis-strike-through
|
||
'((default :strike-through t)
|
||
(((class color) (min-colors 88) (background light))
|
||
:foreground "#505050")
|
||
(((class color) (min-colors 88) (background dark))
|
||
:foreground "#a8a8a8"))
|
||
"My strike-through emphasis for Org.")
|
||
|
||
Or we can just change the color of the line that strikes through the
|
||
text to, for example, a shade of red:
|
||
|
||
(defface my-org-emphasis-strike-through
|
||
'((((class color) (min-colors 88) (background light))
|
||
:strike-through "#972500")
|
||
(((class color) (min-colors 88) (background dark))
|
||
:strike-through "#ef8b50"))
|
||
"My strike-through emphasis for Org.")
|
||
|
||
It is possible to combine those effects:
|
||
|
||
(defface my-org-emphasis-strike-through
|
||
'((((class color) (min-colors 88) (background light))
|
||
:strike-through "#972500" :foreground "#505050")
|
||
(((class color) (min-colors 88) (background dark))
|
||
:strike-through "#ef8b50" :foreground "#a8a8a8"))
|
||
"My strike-through emphasis for Org.")
|
||
|
||
One may inspect the variables ‘modus-themes-operandi-colors’ and
|
||
‘modus-themes-vivendi-colors’ for possible color values. Or call the
|
||
command ‘modus-themes-list-colors’ to show a buffer that previews each
|
||
entry in the palette.
|
||
|
||
*note Visualize the active Modus theme’s palette: Preview theme
|
||
colors.
|
||
|
||
Once we have defined the faces we need, we must update the
|
||
‘org-emphasis-alist’. Given that ‘org-verbatim’ and ‘org-code’ are
|
||
already styled by the themes, it probably is best not to edit them:
|
||
|
||
(setq org-emphasis-alist
|
||
'(("*" my-org-emphasis-bold)
|
||
("/" my-org-emphasis-italic)
|
||
("_" my-org-emphasis-underline)
|
||
("=" org-verbatim verbatim)
|
||
("~" org-code verbatim)
|
||
("+" my-org-emphasis-strike-through)))
|
||
|
||
That’s it! For changes to take effect in already visited Org files,
|
||
invoke ‘M-x org-mode-restart’.
|
||
|
||
|
||
File: modus-themes.info, Node: Update Org block delimiter fontification, Next: Measure color contrast, Prev: Custom Org emphasis faces, Up: Advanced customization
|
||
|
||
5.16 Update Org block delimiter fontification
|
||
=============================================
|
||
|
||
As noted in the section about ‘modus-themes-org-blocks’, Org contains a
|
||
variable that determines whether the block’s begin and end lines are
|
||
extended to the edge of the window (*note Option for org-mode block
|
||
styles: Org mode blocks.). The variable is
|
||
‘org-fontify-whole-block-delimiter-line’.
|
||
|
||
Users who change the style of Org blocks from time to time may prefer
|
||
to automatically update delimiter line fontification, such as with the
|
||
following setup:
|
||
|
||
(defun my-modus-themes-org-fontify-block-delimiter-lines ()
|
||
"Match `org-fontify-whole-block-delimiter-line' to theme style.
|
||
Run this function at the post theme load phase, such as with the
|
||
`modus-themes-after-load-theme-hook'."
|
||
(if (eq modus-themes-org-blocks 'gray-background)
|
||
(setq org-fontify-whole-block-delimiter-line t)
|
||
(setq org-fontify-whole-block-delimiter-line nil)))
|
||
|
||
(add-hook 'modus-themes-after-load-theme-hook
|
||
#'my-modus-themes-org-fontify-block-delimiter-lines)
|
||
|
||
Then ‘M-x org-mode-restart’ for changes to take effect, though manual
|
||
intervention can be circumvented by tweaking the function thus:
|
||
|
||
(defun my-modus-themes-org-fontify-block-delimiter-lines ()
|
||
"Match `org-fontify-whole-block-delimiter-line' to theme style.
|
||
Run this function at the post theme load phase, such as with the
|
||
`modus-themes-after-load-theme-hook'."
|
||
(if (eq modus-themes-org-blocks 'gray-background)
|
||
(setq org-fontify-whole-block-delimiter-line t)
|
||
(setq org-fontify-whole-block-delimiter-line nil))
|
||
(when (derived-mode-p 'org-mode)
|
||
(font-lock-flush)))
|
||
|
||
|
||
File: modus-themes.info, Node: Measure color contrast, Next: Load theme depending on time of day, Prev: Update Org block delimiter fontification, Up: Advanced customization
|
||
|
||
5.17 Measure color contrast
|
||
===========================
|
||
|
||
The themes provide the functions ‘modus-themes-wcag-formula’ and
|
||
‘modus-themes-contrast’. The former is a direct implementation of the
|
||
WCAG formula: <https://www.w3.org/TR/WCAG20-TECHS/G18.html>. It
|
||
calculates the relative luminance of a color value that is expressed in
|
||
hexadecimal RGB notation. While the latter function is just a
|
||
convenient wrapper for comparing the relative luminance between two
|
||
colors.
|
||
|
||
In practice, one needs to work only with ‘modus-themes-contrast’. It
|
||
accepts two color values and returns their contrast ratio. Values range
|
||
from 1 to 21 (lowest to highest). The themes are designed to always be
|
||
equal or higher than 7 for each combination of background and foreground
|
||
that they use (this is the WCAG AAA standard—the most demanding of its
|
||
kind).
|
||
|
||
A couple of examples (rounded numbers):
|
||
|
||
;; Pure white with pure green
|
||
(modus-themes-contrast "#ffffff" "#00ff00")
|
||
;; => 1.37
|
||
;; That is an outright inaccessible combo
|
||
|
||
;; Pure black with pure green
|
||
(modus-themes-contrast "#000000" "#00ff00")
|
||
;; => 15.3
|
||
;; That is a highly accessible combo
|
||
|
||
It does not matter which color value comes first. The ratio is
|
||
always the same.
|
||
|
||
If one does not wish to read all the decimal points, it is possible
|
||
to try something like this:
|
||
|
||
(format "%0.2f" (modus-themes-contrast "#000000" "#00ff00"))
|
||
|
||
While it is fine to perform such calculations on a case-by-case
|
||
basis, it is preferable to implement formulas and tables for more
|
||
demanding tasks. Such instruments are provided by ‘org-mode’ or
|
||
‘orgtbl-mode’, both of which are built into Emacs. Below is such a
|
||
table that derives the contrast ratio of all colors in the first column
|
||
(pure red, green, blue) relative to the color specified in the first row
|
||
of the second column (pure white) and rounds the results:
|
||
|
||
| | #ffffff |
|
||
|---------+---------|
|
||
| #ff0000 | 4.00 |
|
||
| #00ff00 | 1.37 |
|
||
| #0000ff | 8.59 |
|
||
#+tblfm: $2='(modus-themes-contrast $1 @1$2);%0.2f
|
||
|
||
To measure color contrast one needs to start from a known value.
|
||
This typically is the background. The Modus themes define an expanded
|
||
palette in large part because certain colors are only meant to be used
|
||
in combination with some others. Consult the source code for the
|
||
minutia and relevant commentary.
|
||
|
||
Such knowledge may prove valuable while attempting to customize the
|
||
theme’s color palette.
|
||
|
||
|
||
File: modus-themes.info, Node: Load theme depending on time of day, Next: Backdrop for pdf-tools, Prev: Measure color contrast, Up: Advanced customization
|
||
|
||
5.18 Load theme depending on time of day
|
||
========================================
|
||
|
||
While we do provide ‘modus-themes-toggle’ to manually switch between the
|
||
themes, users may also set up their system to perform such a task
|
||
automatically at sunrise and sunset.
|
||
|
||
This can be accomplished by specifying the coordinates of one’s
|
||
location using the built-in ‘solar.el’ and then configuring the
|
||
‘circadian’ package:
|
||
|
||
(use-package solar ; built-in
|
||
:config
|
||
(setq calendar-latitude 35.17
|
||
calendar-longitude 33.36))
|
||
|
||
(use-package circadian ; you need to install this
|
||
:ensure t
|
||
:after solar
|
||
:config
|
||
(setq circadian-themes '((:sunrise . modus-operandi)
|
||
(:sunset . modus-vivendi)))
|
||
(circadian-setup))
|
||
|
||
|
||
File: modus-themes.info, Node: Backdrop for pdf-tools, Next: Toggle themes without reloading them, Prev: Load theme depending on time of day, Up: Advanced customization
|
||
|
||
5.19 Backdrop for pdf-tools
|
||
===========================
|
||
|
||
Most PDF files use a white background for their page, making it
|
||
impossible to discern the file’s boundaries in the buffer while using
|
||
the Modus Operandi theme. To introduce a distinction between the
|
||
buffer’s backdrop and the PDF page’s background, the former must be
|
||
rendered as some shade of gray. Ideally, ‘pdf-tools’ would provide a
|
||
face that the themes could support directly, though this does not seem
|
||
to be the case for the time being. We must thus employ the face
|
||
remapping technique that is documented elsewhere in this document to
|
||
change the buffer-local value of the ‘default’ face.
|
||
|
||
*note Remap face with local value::.
|
||
|
||
To remap the buffer’s backdrop, we start with a function like this
|
||
one:
|
||
|
||
(defun my-pdf-tools-backdrop ()
|
||
(modus-themes-with-colors
|
||
(face-remap-add-relative
|
||
'default
|
||
`(:background ,bg-dim))))
|
||
|
||
(add-hook 'pdf-tools-enabled-hook #'my-pdf-tools-backdrop)
|
||
|
||
The idea is to assign that function to a hook that gets called when
|
||
‘pdf-tools’ renders the document: ‘pdf-tools-enabled-hook’. This is
|
||
enough when you only use one theme. However it has the downside of
|
||
setting the background color value only at render time. In other words,
|
||
the face remapping function does not get evaluated anew whenever the
|
||
theme changes, such as upon invoking ‘M-x modus-themes-toggle’.
|
||
|
||
To have our face remapping adapt gracefully while switching between
|
||
the Modus themes, we need to also account for the current theme and
|
||
control the activation of ‘pdf-view-midnight-minor-mode’. To which end
|
||
we arrive at something like the following, which builds on the above
|
||
example:
|
||
|
||
(defun my-pdf-tools-backdrop ()
|
||
(modus-themes-with-colors
|
||
(face-remap-add-relative
|
||
'default
|
||
`(:background ,bg-dim))))
|
||
|
||
(defun my-pdf-tools-midnight-mode-toggle ()
|
||
(when (derived-mode-p 'pdf-view-mode)
|
||
(if (eq (car custom-enabled-themes) 'modus-vivendi)
|
||
(pdf-view-midnight-minor-mode 1)
|
||
(pdf-view-midnight-minor-mode -1))
|
||
(my-pdf-tools-backdrop)))
|
||
|
||
(defun my-pdf-tools-themes-toggle ()
|
||
(mapc
|
||
(lambda (buf)
|
||
(with-current-buffer buf
|
||
(my-pdf-tools-midnight-mode-toggle)))
|
||
(buffer-list)))
|
||
|
||
(add-hook 'pdf-tools-enabled-hook #'my-pdf-tools-midnight-mode-toggle)
|
||
(add-hook 'modus-themes-after-load-theme-hook #'my-pdf-tools-themes-toggle)
|
||
|
||
With those in place, PDFs have a distinct backdrop for their page,
|
||
while buffers with major-mode as ‘pdf-view-mode’ automatically switches
|
||
to dark mode when ‘modus-themes-toggle’ is called.
|
||
|
||
|
||
File: modus-themes.info, Node: Toggle themes without reloading them, Next: A theme-agnostic hook for theme loading, Prev: Backdrop for pdf-tools, Up: Advanced customization
|
||
|
||
5.20 Toggle themes without reloading them
|
||
=========================================
|
||
|
||
Users who have a stable setup and who only ever need to toggle between
|
||
the themes without triggering a full reload, are better off defining
|
||
their own command which calls ‘enable-theme’ instead of ‘load-theme’:
|
||
|
||
(defun my-modus-themes-toggle ()
|
||
"Toggle between `modus-operandi' and `modus-vivendi' themes.
|
||
This uses `enable-theme' instead of the standard method of
|
||
`load-theme'. The technicalities are covered in the Modus themes
|
||
manual."
|
||
(interactive)
|
||
(pcase (modus-themes--current-theme)
|
||
('modus-operandi (progn (enable-theme 'modus-vivendi)
|
||
(disable-theme 'modus-operandi)))
|
||
('modus-vivendi (progn (enable-theme 'modus-operandi)
|
||
(disable-theme 'modus-vivendi)))
|
||
(_ (error "No Modus theme is loaded; evaluate `modus-themes-load-themes' first"))))
|
||
|
||
*note Differences between loading and enabling::.
|
||
|
||
Recall that ‘modus-themes-toggle’ uses ‘load-theme’.
|
||
|
||
|
||
File: modus-themes.info, Node: A theme-agnostic hook for theme loading, Next: Use more spacious margins or padding in Emacs frames, Prev: Toggle themes without reloading them, Up: Advanced customization
|
||
|
||
5.21 A theme-agnostic hook for theme loading
|
||
============================================
|
||
|
||
The themes are designed with the intent to be useful to Emacs users of
|
||
varying skill levels, from beginners to experts. This means that we try
|
||
to make things easier by not expecting anyone reading this document to
|
||
be proficient in Emacs Lisp or programming in general.
|
||
|
||
Such a case is with the use of ‘modus-themes-after-load-theme-hook’,
|
||
which runs after the ‘modus-themes-load-theme’ function (used by the
|
||
command ‘modus-themes-toggle’). We recommend using that hook for
|
||
advanced customizations, because (1) we know for sure that it is
|
||
available once the themes are loaded, and (2) anyone consulting this
|
||
manual, especially the sections on enabling and loading the themes, will
|
||
be in a good position to benefit from that hook.
|
||
|
||
Advanced users who have a need to switch between the Modus themes and
|
||
other items will find that such a hook does not meet their requirements:
|
||
it only works with the Modus themes and only with the aforementioned
|
||
functions.
|
||
|
||
A theme-agnostic setup can be configured thus:
|
||
|
||
(defvar after-enable-theme-hook nil
|
||
"Normal hook run after enabling a theme.")
|
||
|
||
(defun run-after-enable-theme-hook (&rest _args)
|
||
"Run `after-enable-theme-hook'."
|
||
(run-hooks 'after-enable-theme-hook))
|
||
|
||
(advice-add 'enable-theme :after #'run-after-enable-theme-hook)
|
||
|
||
This creates the ‘after-enable-theme-hook’ and makes it run after
|
||
each call to ‘enable-theme’, which means that it will work for all
|
||
themes and also has the benefit that it does not depend on functions
|
||
such as ‘modus-themes-toggle’ and the others mentioned above.
|
||
‘enable-theme’ is called internally by ‘load-theme’, so the hook works
|
||
everywhere.
|
||
|
||
The downside of the theme-agnostic hook is that any functions added
|
||
to it will likely not be able to benefit from macro calls that read the
|
||
active theme, such as ‘modus-themes-with-colors’. Not all Emacs themes
|
||
have the same capabilities.
|
||
|
||
In this document, we cover ‘modus-themes-after-load-theme-hook’
|
||
though the user can replace it with ‘after-enable-theme-hook’ should
|
||
they need to (provided they understand the implications).
|
||
|
||
|
||
File: modus-themes.info, Node: Use more spacious margins or padding in Emacs frames, Next: Custom hl-todo colors, Prev: A theme-agnostic hook for theme loading, Up: Advanced customization
|
||
|
||
5.22 Use more spacious margins or padding in Emacs frames
|
||
=========================================================
|
||
|
||
[ UPDATE 2023-06-25: Instead of following these instructions, you can
|
||
simply install my ‘spacious-padding’ package from GNU ELPA. It
|
||
implements the padding and provides relevant user options. ]
|
||
|
||
By default, Emacs frames try to maximize the number of characters
|
||
that fit in the current visible portion of the buffer. Users may prefer
|
||
to have some extra padding instead. This can make Emacs frames look
|
||
more pleasant, but also make it easier to identify the currently active
|
||
window.
|
||
|
||
The way to implement such padding is two-fold:
|
||
|
||
1. In the ‘early-init.el’ file instruct Emacs to use a higher value
|
||
for the ‘internal-border-width’ of all frames, as well as for the
|
||
‘right-divider-width’. The former concerns the outer boundaries of
|
||
Emacs frames, while the latter pertains to dividers between Emacs
|
||
windows.
|
||
|
||
2. Make the relevant faces invisible by changing the value of their
|
||
relevant attributes to that of the current theme’s main background.
|
||
|
||
The parameters of Emacs frames are specified in the variables
|
||
‘initial-frame-alist’ and ‘default-frame-alist’. The “initial frame”
|
||
refers to the first frame that appears on Emacs startup. The “default”
|
||
refers to the fallback values that apply to all other frames that Emacs
|
||
creates (unless those are explicitly overridden by a bespoke
|
||
‘make-frame’ call).
|
||
|
||
In detail, first we use the same values for the two frame alist
|
||
variables:
|
||
|
||
;; This must go in the early-init.el so that it applies to the initial
|
||
;; frame.
|
||
(dolist (var '(default-frame-alist initial-frame-alist))
|
||
(add-to-list var '(right-divider-width . 20))
|
||
(add-to-list var '(internal-border-width . 20)))
|
||
|
||
What the ‘dolist’ does is to call ‘add-to-list’ for the two variables
|
||
we specify there. This economizes on typing.
|
||
|
||
Then we define a function that makes the relevant faces invisible.
|
||
The reason we do this with a function is so we can hook it to the “post
|
||
load” phase of a theme, thus applying the new background value
|
||
(otherwise you keep the old background, which likely means that the
|
||
faces will no longer be invisible).
|
||
|
||
(defun my-modus-themes-invisible-dividers ()
|
||
"Make window dividers invisible.
|
||
Add this to the `modus-themes-post-load-hook'."
|
||
(let ((bg (face-background 'default)))
|
||
(custom-set-faces
|
||
`(fringe ((t :background ,bg :foreground ,bg)))
|
||
`(window-divider ((t :background ,bg :foreground ,bg)))
|
||
`(window-divider-first-pixel ((t :background ,bg :foreground ,bg)))
|
||
`(window-divider-last-pixel ((t :background ,bg :foreground ,bg))))))
|
||
|
||
(add-hook 'modus-themes-post-load-hook #'my-modus-themes-invisible-dividers)
|
||
|
||
The above will work only for themes that belong to the Modus family.
|
||
For users of Emacs version 29 or higher, there exists a theme-agnostic
|
||
hook that takes a function with one argument—that of the theme—and calls
|
||
in the the “post enable” phase of theme loading. Here is the above
|
||
snippet, with the necessary tweaks:
|
||
|
||
(defun my-modus-themes-invisible-dividers (_theme)
|
||
"Make window dividers for THEME invisible."
|
||
(let ((bg (face-background 'default)))
|
||
(custom-set-faces
|
||
`(fringe ((t :background ,bg :foreground ,bg)))
|
||
`(window-divider ((t :background ,bg :foreground ,bg)))
|
||
`(window-divider-first-pixel ((t :background ,bg :foreground ,bg)))
|
||
`(window-divider-last-pixel ((t :background ,bg :foreground ,bg))))))
|
||
|
||
(add-hook 'enable-theme-functions #'my-modus-themes-invisible-dividers)
|
||
|
||
Users of older versions of Emacs can read the entry herein about
|
||
defining their own theme-agnostic hook (*note A theme-agnostic hook for
|
||
theme loading::).
|
||
|
||
|
||
File: modus-themes.info, Node: Custom hl-todo colors, Next: Add support for solaire-mode, Prev: Use more spacious margins or padding in Emacs frames, Up: Advanced customization
|
||
|
||
5.23 Custom hl-todo colors
|
||
==========================
|
||
|
||
The ‘hl-todo’ package provides the user option ‘hl-todo-keyword-faces’:
|
||
it specifies a pair of keyword and corresponding color value. The Modus
|
||
themes configure that option in the interest of legibility. While this
|
||
works for our purposes, users may still prefer to apply their custom
|
||
values, in which case the following approach is necessary:
|
||
|
||
(defun my-modus-themes-hl-todo-faces ()
|
||
(setq hl-todo-keyword-faces '(("TODO" . "#ff0000")
|
||
("HACK" . "#ffff00")
|
||
("XXX" . "#00ffff")
|
||
("NOTE" . "#ff00ff"))))
|
||
|
||
(add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-hl-todo-faces)
|
||
|
||
Or include a ‘let’ form, if needed:
|
||
|
||
(defun my-modus-themes-hl-todo-faces ()
|
||
(let ((red "#ff0000")
|
||
(blue "#0000ff"))
|
||
(setq hl-todo-keyword-faces `(("TODO" . ,blue)
|
||
("HACK" . ,red)
|
||
("XXX" . ,red)
|
||
("NOTE" . ,blue)))))
|
||
|
||
(add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-hl-todo-faces)
|
||
|
||
Normally, we do not touch user options, though this is an exception:
|
||
otherwise the defaults are not always legible.
|
||
|
||
|
||
File: modus-themes.info, Node: Add support for solaire-mode, Prev: Custom hl-todo colors, Up: Advanced customization
|
||
|
||
5.24 Add support for solaire-mode
|
||
=================================
|
||
|
||
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 defaultsuch 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.
|
||
|
||
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 elsewhere in this manual:
|
||
|
||
*note Advanced customization::.
|
||
|
||
*note Use theme colors in code with modus-themes-with-colors::.
|
||
|
||
(defun my-modus-themes-custom-faces ()
|
||
(modus-themes-with-colors
|
||
(custom-set-faces
|
||
`(solaire-default-face ((,c :inherit default :background ,bg-dim :foreground ,fg-dim)))
|
||
`(solaire-line-number-face ((,c :inherit solaire-default-face :foreground ,fg-unfocused)))
|
||
`(solaire-hl-line-face ((,c :background ,bg-active)))
|
||
`(solaire-org-hide-face ((,c :background ,bg-dim :foreground ,bg-dim))))))
|
||
|
||
(add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-custom-faces)
|
||
|
||
As always, re-load the theme for changes to take effect.
|
||
|
||
|
||
File: modus-themes.info, Node: Face coverage, Next: Notes on individual packages, Prev: Advanced customization, Up: Top
|
||
|
||
6 Face coverage
|
||
***************
|
||
|
||
The Modus themes try to provide as close to full face coverage as
|
||
possible. This is necessary to ensure a consistently accessible reading
|
||
experience across all available interfaces.
|
||
|
||
* Menu:
|
||
|
||
* Supported packages:: Full list of covered face groups
|
||
* Indirectly covered packages::
|
||
|
||
|
||
File: modus-themes.info, Node: Supported packages, Next: Indirectly covered packages, Up: Face coverage
|
||
|
||
6.1 Full support for packages or face groups
|
||
============================================
|
||
|
||
This list will always be updated to reflect the current state of the
|
||
project. The idea is to offer an overview of the known status of all
|
||
affected face groups. The items with an appended asterisk ‘*’ tend to
|
||
have lots of extensions, so the “full support” may not be 100% true…
|
||
|
||
• ace-window
|
||
• agda2-mode
|
||
• all-the-icons
|
||
• all-the-icons-dired
|
||
• all-the-icons-ibuffer
|
||
• annotate
|
||
• ansi-color
|
||
• anzu
|
||
• auctex and TeX
|
||
• auto-dim-other-buffers
|
||
• avy
|
||
• bbdb
|
||
• binder
|
||
• bongo
|
||
• boon
|
||
• bookmark
|
||
• calendar and diary
|
||
• centaur-tabs
|
||
• change-log and log-view (such as ‘vc-print-log’,
|
||
‘vc-print-root-log’)
|
||
• chart
|
||
• cider
|
||
• circe
|
||
• citar
|
||
• clojure-mode
|
||
• column-enforce-mode
|
||
• company-mode*
|
||
• compilation-mode
|
||
• completions
|
||
• consult
|
||
• corfu
|
||
• corfu-quick
|
||
• counsel*
|
||
• cperl-mode
|
||
• crontab-mode
|
||
• csv-mode
|
||
• ctrlf
|
||
• custom (what you get with ‘M-x customize’)
|
||
• dashboard
|
||
• deadgrep
|
||
• deft
|
||
• devdocs
|
||
• dictionary
|
||
• diff-hl
|
||
• diff-mode
|
||
• dim-autoload
|
||
• dired
|
||
• dired-async
|
||
• dired-git
|
||
• dired-git-info
|
||
• dired-narrow
|
||
• dired-subtree
|
||
• diredfl
|
||
• disk-usage
|
||
• display-fill-column-indicator-mode
|
||
• doom-modeline
|
||
• ediff
|
||
• ein (Emacs IPython Notebook)
|
||
• eglot
|
||
• el-search
|
||
• eldoc-box
|
||
• elfeed
|
||
• elfeed-score
|
||
• elpher
|
||
• embark
|
||
• ement
|
||
• emms
|
||
• enh-ruby-mode (enhanced-ruby-mode)
|
||
• epa
|
||
• erc
|
||
• ert
|
||
• erts-mode [Part of 4.3.0-dev.]
|
||
• eshell
|
||
• eshell-fringe-status
|
||
• evil* (evil-mode)
|
||
• eww
|
||
• exwm
|
||
• eyebrowse
|
||
• flycheck
|
||
• flycheck-color-mode-line
|
||
• flycheck-indicator
|
||
• flymake
|
||
• flyspell
|
||
• flx
|
||
• focus
|
||
• fold-this
|
||
• font-lock (generic syntax highlighting)
|
||
• geiser
|
||
• git-commit
|
||
• git-gutter (and variants)
|
||
• git-rebase
|
||
• git-timemachine
|
||
• gnus
|
||
• gotest
|
||
• golden-ratio-scroll-screen
|
||
• helpful
|
||
• highlight-numbers
|
||
• highlight-parentheses (*note Note on highlight-parentheses.el: Note
|
||
on highlight-parenthesesel.)
|
||
• highlight-thing
|
||
• hl-fill-column
|
||
• hl-line-mode
|
||
• hl-todo
|
||
• hydra
|
||
• ibuffer
|
||
• icomplete
|
||
• ido-mode
|
||
• iedit
|
||
• iflipb
|
||
• image-dired
|
||
• imenu-list
|
||
• indium
|
||
• info
|
||
• info+ (info-plus)
|
||
• info-colors
|
||
• ioccur
|
||
• isearch, occur, etc.
|
||
• ivy*
|
||
• ivy-posframe
|
||
• jira (org-jira)
|
||
• jit-spell
|
||
• jinx
|
||
• journalctl-mode
|
||
• js2-mode
|
||
• julia
|
||
• kaocha-runner
|
||
• keycast
|
||
• ledger-mode
|
||
• leerzeichen
|
||
• line numbers (‘display-line-numbers-mode’ and global variant)
|
||
• magit
|
||
• make-mode
|
||
• man
|
||
• marginalia
|
||
• markdown-mode
|
||
• markup-faces (‘adoc-mode’)
|
||
• messages
|
||
• minimap
|
||
• mode-line
|
||
• mood-line
|
||
• mpdel
|
||
• mu4e
|
||
• multiple-cursors
|
||
• nerd-icons [Part of 4.3.0-dev.]
|
||
• nerd-icons-dired [Part of 4.3.0-dev.]
|
||
• nerd-icons-ibuffer [Part of 4.3.0-dev.]
|
||
• neotree
|
||
• notmuch
|
||
• num3-mode
|
||
• nxml-mode
|
||
• olivetti
|
||
• orderless
|
||
• org*
|
||
• org-journal
|
||
• org-noter
|
||
• org-pomodoro
|
||
• org-recur
|
||
• org-roam
|
||
• org-superstar
|
||
• org-table-sticky-header
|
||
• org-tree-slide
|
||
• origami
|
||
• outline-mode
|
||
• outline-minor-faces
|
||
• package (what you get with ‘M-x list-packages’)
|
||
• page-break-lines
|
||
• pandoc-mode
|
||
• paren-face
|
||
• pass
|
||
• pdf-tools
|
||
• persp-mode
|
||
• perspective
|
||
• popup
|
||
• powerline
|
||
• prism (*note Note for prism.el: Note for prism.)
|
||
• prescient
|
||
• proced
|
||
• prodigy
|
||
• pulse
|
||
• pyim
|
||
• quick-peek
|
||
• rainbow-delimiters
|
||
• rcirc
|
||
• rcirc-color
|
||
• recursion-indicator
|
||
• regexp-builder (also known as ‘re-builder’)
|
||
• rg (rg.el)
|
||
• ripgrep
|
||
• rmail
|
||
• rst-mode
|
||
• ruler-mode
|
||
• sesman
|
||
• shell-script-mode
|
||
• shortdoc
|
||
• show-paren-mode
|
||
• shr
|
||
• side-notes
|
||
• sieve-mode
|
||
• skewer-mode
|
||
• slime (slbd)
|
||
• sly
|
||
• smart-mode-line
|
||
• smerge
|
||
• speedbar
|
||
• spell-fu
|
||
• stripes
|
||
• suggest
|
||
• switch-window
|
||
• swiper
|
||
• symbol-overlay
|
||
• syslog-mode
|
||
• tab-bar-mode
|
||
• tab-line-mode
|
||
• table (built-in ‘table.el’)
|
||
• telega
|
||
• terraform-mode
|
||
• term
|
||
• textsec
|
||
• transient (pop-up windows such as Magit’s)
|
||
• trashed
|
||
• tree-sitter
|
||
• tty-menu
|
||
• tuareg
|
||
• typescript
|
||
• undo-tree
|
||
• vc (‘vc-dir.el’, ‘vc-hooks.el’)
|
||
• vertico
|
||
• vertico-quick
|
||
• vimish-fold
|
||
• visible-mark
|
||
• visual-regexp
|
||
• vterm
|
||
• vundo
|
||
• wcheck-mode
|
||
• web-mode
|
||
• wgrep
|
||
• which-function-mode
|
||
• which-key
|
||
• whitespace-mode
|
||
• window-divider-mode
|
||
• writegood-mode
|
||
• woman
|
||
• xah-elisp-mode
|
||
• xterm-color (and ansi-colors)
|
||
• yaml-mode
|
||
• yasnippet
|
||
|
||
Plus many other miscellaneous faces that are provided by Emacs.
|
||
|
||
|
||
File: modus-themes.info, Node: Indirectly covered packages, Prev: Supported packages, Up: Face coverage
|
||
|
||
6.2 Indirectly covered packages
|
||
===============================
|
||
|
||
These do not require any extra styles because they are configured to
|
||
inherit from some basic faces or their dependencies which are directly
|
||
supported by the themes.
|
||
|
||
• ag
|
||
• apropos
|
||
• apt-sources-list
|
||
• bbdb
|
||
• bm
|
||
• breakpoint (provided by the built-in ‘gdb-mi.el’ library)
|
||
• buffer-expose
|
||
• bufler
|
||
• counsel-notmuch
|
||
• counsel-org-capture-string
|
||
• css-mode
|
||
• dashboard (emacs-dashboard)
|
||
• define-word
|
||
• denote
|
||
• disk-usage
|
||
• dtache
|
||
• dynamic-ruler
|
||
• easy-kill
|
||
• ebdb
|
||
• edit-indirect
|
||
• egerrit
|
||
• elfeed-summary
|
||
• evil-owl
|
||
• flyspell-correct
|
||
• fortran-mode
|
||
• freeze-it
|
||
• forge
|
||
• git-walktree
|
||
• goggles
|
||
• highlight-defined
|
||
• highlight-escape-sequences (‘hes-mode’)
|
||
• icomplete-vertical
|
||
• i3wm-config-mode
|
||
• lin
|
||
• minibuffer-line
|
||
• no-emoji
|
||
• org-remark
|
||
• parrot
|
||
• perl-mode
|
||
• php-mode
|
||
• pulsar
|
||
• rjsx-mode
|
||
• side-hustle
|
||
• spell-fu
|
||
• swift-mode
|
||
• tab-bar-echo-area
|
||
• tide
|
||
• undo-hl
|
||
• vdiff
|
||
• vertico-indexed
|
||
• vertico-mouse
|
||
• xref
|
||
|
||
|
||
File: modus-themes.info, Node: Notes on individual packages, Next: Frequently Asked Questions, Prev: Face coverage, Up: Top
|
||
|
||
7 Notes on individual packages
|
||
******************************
|
||
|
||
This section covers information that may be of interest to users of
|
||
individual packages.
|
||
|
||
* Menu:
|
||
|
||
* Note on calendar.el weekday and weekend colors: Note on calendarel weekday and weekend colors.
|
||
* Note on git-gutter in Doom Emacs::
|
||
* Note on php-mode multiline comments::
|
||
* Note on underlines in compilation buffers::
|
||
* Note on inline Latex in Org buffers::
|
||
* Note on dimmer.el: Note on dimmerel.
|
||
* Note on display-fill-column-indicator-mode::
|
||
* Note on highlight-parentheses.el: Note on highlight-parenthesesel.
|
||
* Note on mmm-mode.el background colors: Note on mmm-modeel background colors.
|
||
* Note for prism::
|
||
* Note on company-mode overlay pop-up::
|
||
* Note on ERC escaped color sequences::
|
||
* Note on powerline or spaceline::
|
||
* Note on SHR colors::
|
||
* Note on SHR fonts::
|
||
* Note on Ement colors and fonts::
|
||
* Note on pdf-tools link hints::
|
||
* Note on the Notmuch logo::
|
||
* Note on goto-address-mode faces::
|
||
|
||
|
||
File: modus-themes.info, Node: Note on calendarel weekday and weekend colors, Next: Note on git-gutter in Doom Emacs, Up: Notes on individual packages
|
||
|
||
7.1 Note on calendar.el weekday and weekend colors
|
||
==================================================
|
||
|
||
By default, the ‘M-x calendar’ interface differentiates weekdays from
|
||
weekends by applying a gray color to the former and a faint red to the
|
||
latter. The idea for this approach is that the weekend should serve as
|
||
a subtle warning that no work is supposed to be done on that day, per
|
||
the design of traditional calendars.
|
||
|
||
Users who prefer all days to look the same can configure the variable
|
||
‘calendar-weekend-days’ to either use gray of weekdays or the faint red
|
||
of weekends uniformly.
|
||
|
||
;; All are treated like weekdays (gray color)
|
||
(setq calendar-weekend-days nil)
|
||
|
||
;; All are treated like weekends (red-faint color)
|
||
(setq calendar-weekend-days (number-sequence 0 6))
|
||
|
||
;; The default marks the Saturday and Sunday as the weekend
|
||
(setq calendar-weekend-days '(0 6))
|
||
|
||
For changes to take effect, the Calendar buffer needs to be generated
|
||
anew.
|
||
|
||
|
||
File: modus-themes.info, Node: Note on git-gutter in Doom Emacs, Next: Note on php-mode multiline comments, Prev: Note on calendarel weekday and weekend colors, Up: Notes on individual packages
|
||
|
||
7.2 Note on git-gutter in Doom Emacs
|
||
====================================
|
||
|
||
The ‘git-gutter’ and ‘git-gutter-fr’ packages default to drawing bitmaps
|
||
for the indicators they display (e.g. bitmap of a plus sign for added
|
||
lines). In Doom Emacs, these bitmaps are replaced with contiguous lines
|
||
which may look nicer, but require a change to the foreground of the
|
||
relevant faces to yield the desired color combinations.
|
||
|
||
Since this is Doom-specific, we urge users to apply changes in their
|
||
local setup. Below is some sample code, based on what we cover at
|
||
length elsewhere in this manual:
|
||
|
||
*note Advanced customization::.
|
||
|
||
*note Use theme colors in code with modus-themes-with-colors::.
|
||
|
||
(defun my-modus-themes-custom-faces ()
|
||
(modus-themes-with-colors
|
||
(custom-set-faces
|
||
;; Make foreground the same as background for a uniform bar on
|
||
;; Doom Emacs.
|
||
;;
|
||
;; Doom should not be implementing such hacks because themes
|
||
;; cannot support them:
|
||
;; <https://protesilaos.com/codelog/2022-08-04-doom-git-gutter-modus-themes/>.
|
||
`(git-gutter-fr:added ((,c :foreground ,bg-added-fringe)))
|
||
`(git-gutter-fr:deleted ((,c :foreground ,bg-removed-fringe)))
|
||
`(git-gutter-fr:modified ((,c :foreground ,bg-changed-fringe))))))
|
||
|
||
(add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-custom-faces)
|
||
|
||
As always, re-load the theme for changes to take effect.
|
||
|
||
If the above does not work, try this instead:
|
||
|
||
(after! modus-themes
|
||
(modus-themes-with-colors
|
||
(custom-set-faces
|
||
;; Make foreground the same as background for a uniform bar on
|
||
;; Doom Emacs.
|
||
;;
|
||
;; Doom should not be implementing such hacks because themes
|
||
;; cannot support them:
|
||
;; <https://protesilaos.com/codelog/2022-08-04-doom-git-gutter-modus-themes/>.
|
||
`(git-gutter-fr:added ((,c :foreground ,bg-added-intense)))
|
||
`(git-gutter-fr:deleted ((,c :foreground ,bg-removed-intense)))
|
||
`(git-gutter-fr:modified ((,c :foreground ,bg-changed-intense))))))
|
||
|
||
|
||
File: modus-themes.info, Node: Note on php-mode multiline comments, Next: Note on underlines in compilation buffers, Prev: Note on git-gutter in Doom Emacs, Up: Notes on individual packages
|
||
|
||
7.3 Note on php-mode multiline comments
|
||
=======================================
|
||
|
||
Depending on your build of Emacs and/or the environment it runs in,
|
||
multiline comments in PHP with the ‘php-mode’ package use the
|
||
‘font-lock-doc-face’ instead of ‘font-lock-comment-face’.
|
||
|
||
This seems to make all comments use the appropriate face:
|
||
|
||
(defun my-multine-comments ()
|
||
(setq-local c-doc-face-name 'font-lock-comment-face))
|
||
|
||
(add-hook 'php-mode-hook #'my-multine-comments)
|
||
|
||
As always, re-load the theme for changes to take effect.
|
||
|
||
|
||
File: modus-themes.info, Node: Note on underlines in compilation buffers, Next: Note on inline Latex in Org buffers, Prev: Note on php-mode multiline comments, Up: Notes on individual packages
|
||
|
||
7.4 Note on underlines in compilation buffers
|
||
=============================================
|
||
|
||
Various buffers that produce compilation results or run tests on code
|
||
apply an underline to the file names they reference or to relevant
|
||
messages. Users may consider this unnecessary or excessive.
|
||
|
||
To outright disable the effect, use this (buffers need to be
|
||
generated anew):
|
||
|
||
(setq compilation-message-face nil)
|
||
|
||
If some element of differentiation is still desired, a good option is
|
||
to render the affected text with the ‘italic’ face:
|
||
|
||
(setq compilation-message-face 'italic)
|
||
|
||
*note Configure bold and italic faces::.
|
||
|
||
|
||
File: modus-themes.info, Node: Note on inline Latex in Org buffers, Next: Note on dimmerel, Prev: Note on underlines in compilation buffers, Up: Notes on individual packages
|
||
|
||
7.5 Note on inline Latex in Org buffers
|
||
=======================================
|
||
|
||
Org can work with inline latex and related syntax. To actually fontify
|
||
those constructs, set the variable ‘org-highlight-latex-and-related’ to
|
||
the desired list of values (per its doc string). For example:
|
||
|
||
(setq org-highlight-latex-and-related '(latex script))
|
||
|
||
Remember to use ‘M-x org-mode-restart’ for changes to take effect.
|
||
|
||
|
||
File: modus-themes.info, Node: Note on dimmerel, Next: Note on display-fill-column-indicator-mode, Prev: Note on inline Latex in Org buffers, Up: Notes on individual packages
|
||
|
||
7.6 Note on dimmer.el
|
||
=====================
|
||
|
||
The ‘dimmer.el’ library by Neil Okamoto can be configured to
|
||
automatically dim the colors of inactive Emacs windows. To guarantee
|
||
consistent results with the Modus themes, we suggest some tweaks to the
|
||
default styles, such as in this minimal setup:
|
||
|
||
(use-package dimmer
|
||
:config
|
||
(setq dimmer-fraction 0.3)
|
||
(setq dimmer-adjustment-mode :foreground)
|
||
(setq dimmer-use-colorspace :rgb)
|
||
|
||
(dimmer-mode 1))
|
||
|
||
Of the above, we strongly recommend the RGB color space because it is
|
||
the one that remains faithful to the hueness of the colors used by the
|
||
themes. Whereas the default CIELAB space has a tendency to distort
|
||
colors in addition to applying the dim effect, which can be somewhat
|
||
disorienting.
|
||
|
||
The value of the ‘dimmer-fraction’ has been selected empirically.
|
||
Users might prefer to tweak it further (increasing it makes the dim
|
||
effect more pronounced).
|
||
|
||
Changing the ‘dimmer-adjustment-mode’ is a matter of preference.
|
||
Though because the Modus themes use black and white as their base
|
||
colors, any other value for that variable will turn the main background
|
||
gray. This inadvertently leads to the opposite of the intended utility
|
||
of this package: it draws too much attention to unfocused windows.
|
||
|
||
|
||
File: modus-themes.info, Node: Note on display-fill-column-indicator-mode, Next: Note on highlight-parenthesesel, Prev: Note on dimmerel, Up: Notes on individual packages
|
||
|
||
7.7 Note on display-fill-column-indicator-mode
|
||
==============================================
|
||
|
||
The ‘display-fill-column-indicator-mode’ uses a typographic character to
|
||
draw its line. This has the downside of creating a dashed line. The
|
||
dashes are further apart depending on how tall the font’s glyph height
|
||
is and what integer the ‘line-spacing’ is set to.
|
||
|
||
At the theme level we eliminate this effect by making the character
|
||
one pixel tall: the line is contiguous. Users who prefer the dashed
|
||
line are advised to change the ‘fill-column-indicator’ face, as
|
||
explained elsewhere in this document. For example:
|
||
|
||
(modus-themes-with-colors
|
||
(custom-set-faces
|
||
`(fill-column-indicator ((,c :foreground ,bg-active)))))
|
||
|
||
*note Use theme colors in code with modus-themes-with-colors::.
|
||
|
||
To make the line thicker, set the height to be equal to the base font
|
||
size instead of the one pixel we use. This is done by specifying a rate
|
||
instead of an absolute number, as in ‘:height 1.0’ versus ‘:height 1’.
|
||
For example:
|
||
|
||
(modus-themes-with-colors
|
||
(custom-set-faces
|
||
`(fill-column-indicator ((,c :height 1.0 :background ,bg-inactive :foreground ,bg-inactive)))))
|
||
|
||
|
||
File: modus-themes.info, Node: Note on highlight-parenthesesel, Next: Note on mmm-modeel background colors, Prev: Note on display-fill-column-indicator-mode, Up: Notes on individual packages
|
||
|
||
7.8 Note on highlight-parentheses.el
|
||
====================================
|
||
|
||
The ‘highlight-parentheses’ package provides contextual coloration of
|
||
surrounding parentheses, highlighting only those which are around the
|
||
point. The package expects users to customize the applicable colors on
|
||
their own by configuring certain variables.
|
||
|
||
To make the Modus themes work as expected with this, we need to use
|
||
some of the techniques that are discussed at length in the various
|
||
“Do-It-Yourself” (DIY) sections, which provide insight into the more
|
||
advanced customization options of the themes.
|
||
|
||
*note Advanced customization::.
|
||
|
||
In the following example, we are assuming that the user wants to (i)
|
||
re-use color variables provided by the themes, (ii) be able to retain
|
||
their tweaks while switching between ‘modus-operandi’ and
|
||
‘modus-vivendi’, and (iii) have the option to highlight either the
|
||
foreground of the parentheses or the background as well.
|
||
|
||
We start by defining our own variable, which will serve as a toggle
|
||
between foreground and background coloration styles:
|
||
|
||
(defvar my-highlight-parentheses-use-background t
|
||
"Prefer `highlight-parentheses-background-colors'.")
|
||
|
||
Then we can update our preference with this:
|
||
|
||
;; Set to nil to disable backgrounds.
|
||
(setq my-highlight-parentheses-use-background nil)
|
||
|
||
To re-use colors from the themes, we must wrap our code in the
|
||
‘modus-themes-with-colors’ macro. Our implementation must interface
|
||
with the variables ‘highlight-parentheses-background-colors’ and/or
|
||
‘highlight-parentheses-colors’.
|
||
|
||
So we can have something like this (the doc string of
|
||
‘modus-themes-with-colors’ explains where the names of the colors can be
|
||
found):
|
||
|
||
(modus-themes-with-colors
|
||
;; Our preference for setting either background or foreground
|
||
;; styles, depending on `my-highlight-parentheses-use-background'.
|
||
(if my-highlight-parentheses-use-background
|
||
|
||
;; Here we set color combinations that involve both a background
|
||
;; and a foreground value.
|
||
(setq highlight-parentheses-background-colors (list bg-cyan-intense
|
||
bg-magenta-intense
|
||
bg-green-intense
|
||
bg-yellow-intense)
|
||
highlight-parentheses-colors (list cyan
|
||
magenta
|
||
green
|
||
yellow))
|
||
|
||
;; And here we pass only foreground colors while disabling any
|
||
;; backgrounds.
|
||
(setq highlight-parentheses-colors (list green-intense
|
||
magenta-intense
|
||
blue-intense
|
||
red-intense)
|
||
highlight-parentheses-background-colors nil)))
|
||
|
||
;; Include this if you also want to make the parentheses bold:
|
||
(set-face-attribute 'highlight-parentheses-highlight nil :inherit 'bold)
|
||
|
||
;; Our changes must be evaluated before enabling the relevant mode, so
|
||
;; this comes last.
|
||
(global-highlight-parentheses-mode 1)
|
||
|
||
For our changes to persist while switching between the Modus themes,
|
||
we need to include them in a function which can then get passed to
|
||
‘modus-themes-after-load-theme-hook’. This is the complete
|
||
implementation:
|
||
|
||
;; Configurations for `highlight-parentheses':
|
||
(require 'highlight-parentheses)
|
||
|
||
(defvar my-highlight-parentheses-use-background t
|
||
"Prefer `highlight-parentheses-background-colors'.")
|
||
|
||
(setq my-highlight-parentheses-use-background nil) ; Set to nil to disable backgrounds
|
||
|
||
(defun my-modus-themes-highlight-parentheses ()
|
||
(modus-themes-with-colors
|
||
;; Our preference for setting either background or foreground
|
||
;; styles, depending on `my-highlight-parentheses-use-background'.
|
||
(if my-highlight-parentheses-use-background
|
||
|
||
;; Here we set color combinations that involve both a background
|
||
;; and a foreground value.
|
||
(setq highlight-parentheses-background-colors (list bg-cyan-intense
|
||
bg-magenta-intense
|
||
bg-green-intense
|
||
bg-yellow-intense)
|
||
highlight-parentheses-colors (list cyan
|
||
magenta
|
||
green
|
||
yellow))
|
||
|
||
;; And here we pass only foreground colors while disabling any
|
||
;; backgrounds.
|
||
(setq highlight-parentheses-colors (list green-intense
|
||
magenta-intense
|
||
blue-intense
|
||
red-intense)
|
||
highlight-parentheses-background-colors nil)))
|
||
|
||
;; Include this if you also want to make the parentheses bold:
|
||
(set-face-attribute 'highlight-parentheses-highlight nil :inherit 'bold)
|
||
|
||
;; Our changes must be evaluated before enabling the relevant mode, so
|
||
;; this comes last.
|
||
(global-highlight-parentheses-mode 1))
|
||
|
||
(add-hook 'modus-themes-after-load-theme-hook #'my-modus-themes-highlight-parentheses)
|
||
|
||
As always, re-load the theme for changes to take effect.
|
||
|
||
|
||
File: modus-themes.info, Node: Note on mmm-modeel background colors, Next: Note for prism, Prev: Note on highlight-parenthesesel, Up: Notes on individual packages
|
||
|
||
7.9 Note on mmm-mode.el background colors
|
||
=========================================
|
||
|
||
The faces used by ‘mmm-mode.el’ are expected to have a colorful
|
||
background, while they should not touch any foreground value. The idea
|
||
is that they must not interfere with existing fontification. Those
|
||
background colors need to be distinct from each other, such as an
|
||
unambiguous red juxtaposed with a clear blue.
|
||
|
||
While this design may be internally consistent with the raison d’être
|
||
of that library, it inevitably produces inaccessible color combinations.
|
||
|
||
There are two competing goals at play:
|
||
|
||
1. Legibility of the text, understood as the contrast ratio between
|
||
the background and the foreground.
|
||
|
||
2. Semantic precision of each face which entails faithfulness to
|
||
color-coding of the underlying background.
|
||
|
||
As the Modus themes are designed with the express purpose of
|
||
conforming with the first point, we have to forgo the apparent
|
||
color-coding of the background elements. Instead we use subtle colors
|
||
that do not undermine the legibility of the affected text while they
|
||
still offer a sense of added context.
|
||
|
||
Users who might prefer to fall below the minimum 7:1 contrast ratio
|
||
in relative luminance (the accessibility target we conform with), can
|
||
opt to configure the relevant faces on their own.
|
||
|
||
*note Use theme colors in code with modus-themes-with-colors::.
|
||
|
||
This example uses more vivid background colors, though it comes at
|
||
the very high cost of degraded legibility.
|
||
|
||
(modus-themes-with-colors
|
||
(custom-set-faces
|
||
`(mmm-cleanup-submode-face ((,c :background ,bg-yellow-intense)))
|
||
`(mmm-code-submode-face ((,c :background ,bg-inactive)))
|
||
`(mmm-comment-submode-face ((,c :background ,bg-blue-intense)))
|
||
`(mmm-declaration-submode-face ((,c :background ,bg-cyan-intense)))
|
||
`(mmm-default-submode-face ((,c :background ,bg-dim)))
|
||
`(mmm-init-submode-face ((,c :background ,bg-magenta-intense)))
|
||
`(mmm-output-submode-face ((,c :background ,bg-red-intense)))
|
||
`(mmm-special-submode-face ((,c :background ,bg-green-intense)))))
|
||
|
||
|
||
File: modus-themes.info, Node: Note for prism, Next: Note on company-mode overlay pop-up, Prev: Note on mmm-modeel background colors, Up: Notes on individual packages
|
||
|
||
7.10 Note on prism.el
|
||
=====================
|
||
|
||
This package by Adam Porter, aka “alphapapa” or “github-alphapapa”,
|
||
implements an alternative to the typical coloration of code. Instead of
|
||
highlighting the syntactic constructs, it applies color to different
|
||
levels of depth in the code structure.
|
||
|
||
As ‘prism.el’ offers a broad range of customizations, we cannot style
|
||
it directly at the theme level: that would run contrary to the spirit of
|
||
the package. Instead, we may offer preset color schemes. Those should
|
||
offer a starting point for users to adapt to their needs.
|
||
|
||
In the following code snippets, we employ the
|
||
‘modus-themes-with-colors’ macro: *note Use theme colors in code with
|
||
modus-themes-with-colors::.
|
||
|
||
These are the minimum recommended settings with 16 colors:
|
||
|
||
(setq prism-num-faces 16)
|
||
|
||
(prism-set-colors
|
||
:desaturations '(0) ; do not change---may lower the contrast ratio
|
||
:lightens '(0) ; same
|
||
:colors (modus-themes-with-colors
|
||
(list fg-main
|
||
magenta
|
||
cyan-cooler
|
||
magenta-cooler
|
||
blue
|
||
magenta-warmer
|
||
cyan-warmer
|
||
red-cooler
|
||
green
|
||
fg-main
|
||
cyan
|
||
yellow
|
||
blue-warmer
|
||
red-warmer
|
||
green-cooler
|
||
yellow-faint)))
|
||
|
||
With 8 colors:
|
||
|
||
(setq prism-num-faces 8)
|
||
|
||
(prism-set-colors
|
||
:desaturations '(0) ; do not change---may lower the contrast ratio
|
||
:lightens '(0) ; same
|
||
:colors (modus-themes-with-colors
|
||
(list blue
|
||
magenta
|
||
magenta-cooler
|
||
cyan-cooler
|
||
fg-main
|
||
blue-warmer
|
||
red-cooler
|
||
cyan)))
|
||
|
||
And this is with 4 colors, which produces results that are the
|
||
closest to the themes’ default aesthetic:
|
||
|
||
(setq prism-num-faces 4)
|
||
|
||
(prism-set-colors
|
||
:desaturations '(0) ; do not change---may lower the contrast ratio
|
||
:lightens '(0) ; same
|
||
:colors (modus-themes-with-colors
|
||
(list blue
|
||
magenta
|
||
magenta-cooler
|
||
green-warmer)))
|
||
|
||
If you need to apply desaturation and lightening, you can use what
|
||
the ‘prism.el’ documentation recommends, like this (adapting to the
|
||
examples with the 4, 8, 16 colors):
|
||
|
||
(prism-set-colors
|
||
:desaturations (cl-loop for i from 0 below 16 collect (* i 2.5))
|
||
:lightens (cl-loop for i from 0 below 16 collect (* i 2.5))
|
||
:colors (modus-themes-with-colors
|
||
(list fg-main
|
||
cyan-cooler
|
||
magenta-cooler
|
||
magenta)))
|
||
|
||
|
||
File: modus-themes.info, Node: Note on company-mode overlay pop-up, Next: Note on ERC escaped color sequences, Prev: Note for prism, Up: Notes on individual packages
|
||
|
||
7.11 Note on company-mode overlay pop-up
|
||
========================================
|
||
|
||
By default, the ‘company-mode’ pop-up that lists completion candidates
|
||
is drawn using an overlay. This creates alignment issues every time it
|
||
is placed above a piece of text that has a different height than the
|
||
default.
|
||
|
||
The solution recommended by the project’s maintainer is to use an
|
||
alternative front-end for drawing the pop-up which draws child frames
|
||
instead of overlays.(1)(2)
|
||
|
||
Also consider the ‘corfu’ package.
|
||
|
||
---------- Footnotes ----------
|
||
|
||
(1) <https://github.com/company-mode/company-mode/issues/1010>
|
||
|
||
(2) <https://github.com/tumashu/company-posframe/>
|
||
|
||
|
||
File: modus-themes.info, Node: Note on ERC escaped color sequences, Next: Note on powerline or spaceline, Prev: Note on company-mode overlay pop-up, Up: Notes on individual packages
|
||
|
||
7.12 Note on ERC escaped color sequences
|
||
========================================
|
||
|
||
The built-in IRC client ‘erc’ has the ability to colorize any text using
|
||
escape sequences that start with ‘^C’ (inserted with ‘C-q C-c’) and are
|
||
followed by a number for the foreground and background.(1) Possible
|
||
numbers are 0-15, with the first entry being the foreground and the
|
||
second the background, separated by a comma. Like this ‘^C1,6’. The
|
||
minimum setup is this:
|
||
|
||
(add-to-list 'erc-modules 'irccontrols)
|
||
(setq erc-interpret-controls-p t
|
||
erc-interpret-mirc-color t)
|
||
|
||
As this allows users the chance to make arbitrary combinations, it is
|
||
impossible to guarantee a consistently high contrast ratio. All we can
|
||
we do is provide guidance on the combinations that satisfy the
|
||
accessibility standard of the themes:
|
||
|
||
Modus Operandi
|
||
Use foreground color 1 for all backgrounds from 2-15. Like so:
|
||
‘C-q C-c1’ where ‘N’ is the background.
|
||
|
||
Modus Vivendi
|
||
Use foreground color 0 for all backgrounds from 2-13. Use
|
||
foreground ‘1’ for backgrounds 14, 15.
|
||
|
||
Colors 0 and 1 are white and black respectively. So combine them
|
||
together, if you must.
|
||
|
||
---------- Footnotes ----------
|
||
|
||
(1) This page explains the basics, though it is not specific to
|
||
Emacs: <https://www.mirc.com/colors.html>
|
||
|
||
|
||
File: modus-themes.info, Node: Note on powerline or spaceline, Next: Note on SHR colors, Prev: Note on ERC escaped color sequences, Up: Notes on individual packages
|
||
|
||
7.13 Note on powerline or spaceline
|
||
===================================
|
||
|
||
Both Powerline and Spaceline package users will likely need to use the
|
||
command ‘powerline-reset’ whenever they make changes to their themes
|
||
and/or mode line setup.
|
||
|
||
|
||
File: modus-themes.info, Node: Note on SHR colors, Next: Note on SHR fonts, Prev: Note on powerline or spaceline, Up: Notes on individual packages
|
||
|
||
7.14 Note on SHR colors
|
||
=======================
|
||
|
||
Emacs’ HTML rendering library (‘shr.el’) may need explicit configuration
|
||
to respect the theme’s colors instead of whatever specifications the
|
||
webpage provides.
|
||
|
||
Consult the doc string of ‘shr-use-colors’.
|
||
|
||
|
||
File: modus-themes.info, Node: Note on SHR fonts, Next: Note on Ement colors and fonts, Prev: Note on SHR colors, Up: Notes on individual packages
|
||
|
||
7.15 Note on SHR fonts
|
||
======================
|
||
|
||
By default, packages that build on top of the Simple HTML Remember
|
||
(‘shr’) use proportionately spaced fonts. This is controlled by the
|
||
user option ‘shr-use-fonts’, which is set to non-‘nil’ by default. To
|
||
use the standard font instead, set that variable to ‘nil’.
|
||
|
||
*note Font configurations for Org and others::.
|
||
|
||
Packages affected by this are:
|
||
|
||
• elfeed
|
||
• ement
|
||
• eww
|
||
|
||
This is a non-exhaustive list.
|
||
|
||
|
||
File: modus-themes.info, Node: Note on Ement colors and fonts, Next: Note on pdf-tools link hints, Prev: Note on SHR fonts, Up: Notes on individual packages
|
||
|
||
7.16 Note on Ement colors and fonts
|
||
===================================
|
||
|
||
The ‘ement.el’ library by Adam Porter (also known as “alphapapa”)
|
||
defaults to a method of colorizing usernames in a rainbow style. This
|
||
is controlled by the user option ‘ement-room-prism’ and can be disabled
|
||
with:
|
||
|
||
(setq ement-room-prism nil)
|
||
|
||
The contrast ratio of these colors is governed by another user
|
||
option: ‘ement-room-prism-minimum-contrast’. By default, it is set to 6
|
||
which is slightly below our nominal target. Try this instead:
|
||
|
||
(setq ement-room-prism-minimum-contrast 7)
|
||
|
||
With regard to fonts, Ement depends on ‘shr’ (*note Note on SHR
|
||
fonts::).
|
||
|
||
Since we are here, here is an excerpt from Ement’s source code:
|
||
|
||
(defcustom ement-room-prism-minimum-contrast 6
|
||
"Attempt to enforce this minimum contrast ratio for user faces.
|
||
This should be a reasonable number from, e.g. 0-7 or so."
|
||
;; Prot would almost approve of this default. :) I would go all the way
|
||
;; to 7, but 6 already significantly dilutes the colors in some cases.
|
||
:type 'number)
|
||
|
||
Yes, I do approve of that default. Even a 4.5 (the WCAG AA rating)
|
||
would be a good baseline for many themes and/or user configurations.
|
||
Our target is the highest of the sort, though we do not demand that
|
||
everyone conforms with it.
|
||
|
||
|
||
File: modus-themes.info, Node: Note on pdf-tools link hints, Next: Note on the Notmuch logo, Prev: Note on Ement colors and fonts, Up: Notes on individual packages
|
||
|
||
7.17 Note on pdf-tools link hints
|
||
=================================
|
||
|
||
Hints are drawn by ImageMagick (https://imagemagick.org/), not Emacs,
|
||
i.e., ImageMagick doesn’t know about the hint face unless you tell
|
||
ImageMagick about it. By default, only the foreground and background
|
||
color attributes are passed. The below snippet adds to those the
|
||
various font attributes. As it queries various faces, specifically
|
||
‘pdf-links-read-link’ and the faces it inherits, it needs to be added to
|
||
your initialization file after you’ve customized any faces.
|
||
|
||
(use-package pdf-links
|
||
:config
|
||
(let ((spec
|
||
(apply #'append
|
||
(mapcar
|
||
(lambda (name)
|
||
(list name
|
||
(face-attribute 'pdf-links-read-link
|
||
name nil 'default)))
|
||
'(:family :width :weight :slant)))))
|
||
(setq pdf-links-read-link-convert-commands
|
||
`("-density" "96"
|
||
"-family" ,(plist-get spec :family)
|
||
"-stretch" ,(let* ((width (plist-get spec :width))
|
||
(name (symbol-name width)))
|
||
(replace-regexp-in-string "-" ""
|
||
(capitalize name)))
|
||
"-weight" ,(pcase (plist-get spec :weight)
|
||
('ultra-light "Thin")
|
||
('extra-light "ExtraLight")
|
||
('light "Light")
|
||
('semi-bold "SemiBold")
|
||
('bold "Bold")
|
||
('extra-bold "ExtraBold")
|
||
('ultra-bold "Black")
|
||
(_weight "Normal"))
|
||
"-style" ,(pcase (plist-get spec :slant)
|
||
('italic "Italic")
|
||
('oblique "Oblique")
|
||
(_slant "Normal"))
|
||
"-pointsize" "%P"
|
||
"-undercolor" "%f"
|
||
"-fill" "%b"
|
||
"-draw" "text %X,%Y '%c'"))))
|
||
|
||
|
||
File: modus-themes.info, Node: Note on the Notmuch logo, Next: Note on goto-address-mode faces, Prev: Note on pdf-tools link hints, Up: Notes on individual packages
|
||
|
||
7.18 Note on the Notmuch logo
|
||
=============================
|
||
|
||
By default, the “hello” buffer of Notmuch includes a header with the
|
||
programs’ logo and a couple of buttons. The logo has the effect of
|
||
enlarging the height of the line, which negatively impacts the shape of
|
||
those buttons. Disabling the logo fixes the problem:
|
||
|
||
(setq notmuch-show-logo nil)
|
||
|
||
|
||
File: modus-themes.info, Node: Note on goto-address-mode faces, Prev: Note on the Notmuch logo, Up: Notes on individual packages
|
||
|
||
7.19 Note on goto-address-mode faces
|
||
====================================
|
||
|
||
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).
|
||
|
||
|
||
File: modus-themes.info, Node: Frequently Asked Questions, Next: Contributing, Prev: Notes on individual packages, Up: Top
|
||
|
||
8 Frequently Asked Questions
|
||
****************************
|
||
|
||
In this section we provide answers related to some aspects of the Modus
|
||
themes’ design and application.
|
||
|
||
* Menu:
|
||
|
||
* Is the contrast ratio about adjacent colors?::
|
||
* What does it mean to avoid exaggerations?::
|
||
* Why are colors mostly variants of blue, magenta, cyan?: Why are colors mostly variants of blue magenta cyan?.
|
||
* What is the best setup for legibility?::
|
||
* Are these color schemes?::
|
||
* Port the Modus themes to other platforms?::
|
||
|
||
|
||
File: modus-themes.info, Node: Is the contrast ratio about adjacent colors?, Next: What does it mean to avoid exaggerations?, Up: Frequently Asked Questions
|
||
|
||
8.1 Is the contrast ratio about adjacent colors?
|
||
================================================
|
||
|
||
The minimum contrast ratio in relative luminance that the themes conform
|
||
with always refers to any given combination of background and foreground
|
||
colors. If we have some blue colored text next to a magenta one, both
|
||
against a white background, we do not mean to imply that blue:magenta is
|
||
7:1 in terms of relative luminance. Rather, we state that blue:white
|
||
and magenta:white each are 7:1 or higher.
|
||
|
||
The point of reference is always the background. Because colors have
|
||
about the same minimum distance in luminance from their backdrop, they
|
||
necessarily are fairly close to each other in this measure. A possible
|
||
blue:magenta combination would naturally be around 1:1 in contrast of
|
||
the sort here considered.
|
||
|
||
To differentiate between sequential colors, we rely on hueness by
|
||
mapping contrasting hues to adjacent constructs, while avoiding
|
||
exaggerations. A blue next to a magenta can be told apart regardless of
|
||
their respective contrast ratio against their common background.
|
||
Exceptions would be tiny characters in arguably not so realistic cases,
|
||
such as two dots drawn side-by-side which for some reason would need to
|
||
be colored differently. They would still be legible though, which is
|
||
the primary objective of the Modus themes.
|
||
|
||
|
||
File: modus-themes.info, Node: What does it mean to avoid exaggerations?, Next: Why are colors mostly variants of blue magenta cyan?, Prev: Is the contrast ratio about adjacent colors?, Up: Frequently Asked Questions
|
||
|
||
8.2 What does it mean to avoid exaggerations?
|
||
=============================================
|
||
|
||
The Modus themes are designed with restraint, so that their default
|
||
looks do not overdo it with the application of color.
|
||
|
||
*note Customization Options: Customization options.
|
||
|
||
This is the non-quantifiable aspect of the themes’ design: the
|
||
artistic part, if you will. There are a lot of cases where color can be
|
||
used inconsiderately, without accounting for layout, typographic, or
|
||
other properties of the presentation. For example, two headings with
|
||
distinct markers, such as leading asterisks in Org buffers, do not have
|
||
to have highly contrasting hues between them in order to be told apart:
|
||
the added element of contrast in hueness does not contribute
|
||
significantly more to the distinction between the headings than colors
|
||
whose hues are relatively closer to each other in the color space.
|
||
|
||
Exaggerations can be hard to anticipate or identify. Multiple shades
|
||
of blue and magenta in the same context may not seem optimal: one might
|
||
think that it would be better to use highly contrasting hues to ensure
|
||
that all colors stand out, such as by placing blue next to yellow, next
|
||
to magenta, and green. That would, however, be a case of design for its
|
||
own sake; a case where color is being applied without consideration of
|
||
its end results in the given context. Too many contrasting hues in
|
||
close proximity force an erratic rate to how the eye jumps from one
|
||
piece of text to the next. Whereas multiple shades of, say, blue and
|
||
magenta can suffice to tell things apart and avoid excess coloration: a
|
||
harmonious rhythm.
|
||
|
||
|
||
File: modus-themes.info, Node: Why are colors mostly variants of blue magenta cyan?, Next: What is the best setup for legibility?, Prev: What does it mean to avoid exaggerations?, Up: Frequently Asked Questions
|
||
|
||
8.3 Why are colors mostly variants of blue, magenta, cyan?
|
||
==========================================================
|
||
|
||
Due to the innate properties of color, some options are better than
|
||
others for the accessibility purposes of the themes, the stylistic
|
||
consistency between ‘modus-operandi’ and ‘modus-vivendi’, and the
|
||
avoidance of exaggerations in design.
|
||
|
||
*note What does it mean to avoid exaggerations?::
|
||
|
||
What we describe as color is a function of three distinct channels of
|
||
light: red, green, blue. In hexadecimal RGB notation, a color value is
|
||
read as three pairs of red, green, and blue light: ‘#RRGGBB’. Of those
|
||
three, the most luminant is green, while the least luminant is blue.
|
||
|
||
The three basic colors represent each of the channels of light. They
|
||
can be intermixed to give us six colors: red and green derive yellow,
|
||
green and blue make cyan, red and blue turn into magenta.
|
||
|
||
We can test the luminance of each of those against white and black to
|
||
get a sense of how not all colors are equally good for accessibility
|
||
(white is ‘#ffffff’, which means that all three light channels are fully
|
||
luminated, while black is ‘#000000’ meaning that no light is present
|
||
(notwithstanding display technology)).
|
||
|
||
| Name | | #ffffff | #000000 |
|
||
|---------+---------+---------+---------|
|
||
| red | #ff0000 | 4.00 | 5.25 |
|
||
| yellow | #ffff00 | 1.07 | 19.56 |
|
||
| green | #00ff00 | 1.37 | 15.30 |
|
||
| cyan | #00ffff | 1.25 | 16.75 |
|
||
| blue | #0000ff | 8.59 | 2.44 |
|
||
| magenta | #ff00ff | 3.14 | 6.70 |
|
||
|
||
*note Measure color contrast::.
|
||
|
||
By reading this table we learn that every color that has a high level
|
||
of green light (green, yellow, cyan) is virtually unreadable against a
|
||
white background and, conversely, can be easily read against black.
|
||
|
||
We can then infer that red and blue, in different combinations, with
|
||
green acting as calibrator for luminance, will give us fairly moderate
|
||
colors that pass the 7:1 target. Blue with a bit of green produce
|
||
appropriate variants of cyan. Similarly, blue combined with some red
|
||
and hints of green give us suitable shades of purple.
|
||
|
||
Due to the need of maintaining some difference in hueness between
|
||
adjacent colors, it is not possible to make red, green, and yellow the
|
||
main colors, because blue cannot be used to control their luminance and,
|
||
thus the relevant space will shrink considerably.
|
||
|
||
*note Is the contrast ratio about adjacent colors?::
|
||
|
||
This phenomenon is best illustrated by the following table that
|
||
measures the relative luminance of shades of red, yellow, magenta
|
||
against white:
|
||
|
||
| | #ffffff |
|
||
|---------+---------|
|
||
| #990000 | 8.92 |
|
||
| #995500 | 5.75 |
|
||
| #990099 | 7.46 |
|
||
|
||
We notice that equal values of red and blue light in ‘#990099’
|
||
(magenta shade) do not lead to a considerable change in luminance
|
||
compared with ‘#990000’ (red variant). Whereas less amount of green
|
||
light in ‘#995500’ leads to a major drop in luminance relative to white.
|
||
It follows that using the green channel of light to calibrate the
|
||
luminance of colors is more effective than trying to do the same with
|
||
either red or blue (the latter is the least effective in that regard).
|
||
|
||
When we need to work with several colors, it is always better to have
|
||
sufficient manoeuvring space, especially since we cannot pick arbitrary
|
||
colors but only those that satisfy the accessibility objectives of the
|
||
themes.
|
||
|
||
As for why we do not mostly use green, yellow, cyan for the dark
|
||
theme, it is because those colors are far more luminant than their
|
||
counterparts on the other side of the spectrum, so to ensure that they
|
||
all have about the same contrast ratios we would have to alter their
|
||
hueness considerably. In short, the effect would not be optimal as it
|
||
would lead to exaggerations. Plus, it would make ‘modus-vivendi’ look
|
||
completely different than ‘modus-operandi’, to the effect that the two
|
||
could not be properly considered part of the same project.
|
||
|
||
|
||
File: modus-themes.info, Node: What is the best setup for legibility?, Next: Are these color schemes?, Prev: Why are colors mostly variants of blue magenta cyan?, Up: Frequently Asked Questions
|
||
|
||
8.4 What is the best setup for legibility?
|
||
==========================================
|
||
|
||
The Modus themes can be conceptually simplified as combinations of color
|
||
values that account for relative luminance and inner harmony. Those
|
||
qualities do not guarantee that every end-user will have the same
|
||
experience, due to differences between people, but also because of
|
||
variances in hardware capabilities and configurations. For the purposes
|
||
of this document, we may only provide suggestions pertaining to the
|
||
latter case.
|
||
|
||
‘modus-operandi’ is best used outdoors or in a room that either gets
|
||
direct sunlight or has plenty of light. Whereas ‘modus-vivendi’ works
|
||
better when there is not a lot of sunshine or the room has a source of
|
||
light that is preferably a faint and/or warm one. It is possible to use
|
||
‘modus-operandi’ at night and ‘modus-vivendi’ during the day, though
|
||
that will depend on several variables, such as one’s overall perception
|
||
of color, the paint on the walls and how that contributes to the
|
||
impression of lightness in the room, the sense of space within the eye’s
|
||
peripheral vision, hardware specifications, and environmental factors.
|
||
|
||
In general, an additional source of light other than that of the
|
||
monitor can help reduce eye strain: the eyes are more relaxed when they
|
||
do not have to focus on one point to gather light.
|
||
|
||
The monitor’s display settings must be accounted for. Gamma values,
|
||
in particular, need to be calibrated to neither amplify nor distort the
|
||
perception of black. Same principle for sharpness, brightness, and
|
||
contrast as determined by the hardware, which all have an effect on how
|
||
text is read on the screen.
|
||
|
||
There are software level methods on offer, such as the XrandR utility
|
||
for the X Window System (X.org), which can make gamma corrections for
|
||
each of the three channels of light (red, green, blue). For example:
|
||
|
||
xrandr --output LVDS1 --brightness 1.0 --gamma 0.76:0.75:0.68
|
||
|
||
Typography is another variable. Some font families are blurry at
|
||
small point sizes. Others may have a regular weight that is lighter
|
||
(thiner) than that of their peers which may, under certain
|
||
circumstances, cause a halo effect around each glyph.
|
||
|
||
The gist is that legibility cannot be fully solved at the theme
|
||
level. The color combinations may have been optimized for
|
||
accessibility, though the remaining contributing factors in each case
|
||
need to be considered in full.
|
||
|
||
|
||
File: modus-themes.info, Node: Are these color schemes?, Next: Port the Modus themes to other platforms?, Prev: What is the best setup for legibility?, Up: Frequently Asked Questions
|
||
|
||
8.5 Are these color schemes?
|
||
============================
|
||
|
||
No, the Modus themes are not color schemes.
|
||
|
||
A color scheme is a collection of colors. A good color scheme is a
|
||
combination of colors with an inner logic or abstract structure.
|
||
|
||
A theme is a set of patterns that are applied across different
|
||
contexts. A good theme is one that does so with consistency, though not
|
||
uniformity.
|
||
|
||
In practical terms, a color scheme is what one uses when, for
|
||
example, they replace the first sixteen escape sequences of a terminal
|
||
emulator with color values of their preference. The terminal offers the
|
||
option to choose, say, the exact value of what counts as “red”, but does
|
||
not provide the means to control where that is mapped to and whether it
|
||
should also have other qualities such as a bold weight for the
|
||
underlying text or an added background color. In contradistinction,
|
||
Emacs uses constructs known as “faces” which allow the user/developer to
|
||
specify where a given color will be used and whether it should be
|
||
accompanied by other typographic or stylistic attributes.
|
||
|
||
By configuring the multitude of faces on offer we thus control both
|
||
which colors are applied and how they appear in their context. When a
|
||
package wants to render each instance of “foo” with the “bar” face, it
|
||
is not requesting a specific color, which makes things considerably more
|
||
flexible as we can treat “bar” in its own right without necessarily
|
||
having to use some color value that we hardcoded somewhere.
|
||
|
||
Which brings us to the distinction between consistency and uniformity
|
||
where our goal is always the former: we want things to look similar
|
||
across all interfaces, but we must never force a visual identity where
|
||
that runs contrary to the functionality of the given interface. For
|
||
instance, all links are underlined by default yet there are cases such
|
||
as when viewing listings of emails in Gnus (and Mu4e, Notmuch) where (i)
|
||
it is already understood that one must follow the indicator or headline
|
||
to view its contents and (ii) underlining everything would make the
|
||
interface virtually unusable.
|
||
|
||
Again, one must exercise judgement in order to avoid discrimination,
|
||
where “discrimination” refers to:
|
||
|
||
• The treatment of substantially different magnitudes as if they were
|
||
of the same class.
|
||
• Or the treatment of the same class of magnitudes as if they were of
|
||
a different class.
|
||
|
||
(To treat similar things differently; to treat dissimilar things
|
||
alike.)
|
||
|
||
If, in other words, one is to enforce uniformity without accounting
|
||
for the particular requirements of each case—the contextual demands for
|
||
usability beyond matters of color—they are making a not-so-obvious error
|
||
of treating different cases as if they were the same.
|
||
|
||
The Modus themes prioritize “thematic consistency” over abstract
|
||
harmony or regularity among their applicable colors. In concrete terms,
|
||
we do not claim that, say, our yellows are the best complements for our
|
||
blues because we generally avoid using complementary colors
|
||
side-by-side, so it is wrong to optimize for a decontextualised
|
||
blue+yellow combination. Not to imply that our colors do not work well
|
||
together because they do, just to clarify that consistency of context is
|
||
what themes must strive for, and that requires widening the scope of the
|
||
design beyond the particularities of a color scheme.
|
||
|
||
Long story short: color schemes and themes have different
|
||
requirements. Please do not conflate the two.
|
||
|
||
|
||
File: modus-themes.info, Node: Port the Modus themes to other platforms?, Prev: Are these color schemes?, Up: Frequently Asked Questions
|
||
|
||
8.6 Port the Modus themes to other platforms?
|
||
=============================================
|
||
|
||
There is no plan to port the themes to other platforms or text editors.
|
||
I (Protesilaos) only use GNU Emacs and thus cannot maintain code that
|
||
targets software I am either not familiar with or am not using on a
|
||
daily basis.
|
||
|
||
While it is possible to produce a simulacrum based on a given
|
||
template, doing so would run contrary to how this project is maintained
|
||
where details matter greatly.
|
||
|
||
Each program has its own requirements so it won’t always be
|
||
possible—or indeed desirable—to have 1:1 correspondence between what
|
||
applies to Emacs and what should be done elsewhere. No port should ever
|
||
strive to be a copy of the Emacs implementation, as no other program is
|
||
an Emacs equivalent, but instead try to follow the spirit of the design.
|
||
For example, some of the customization options accept a list as their
|
||
value, or an alist, which may not be possible to reproduce on other
|
||
platforms.
|
||
|
||
*note Customization options::.
|
||
|
||
In other words, if something must be done differently on a certain
|
||
editor then that is acceptable so long as (i) the accessibility
|
||
standards are not compromised and (ii) the overall character of the
|
||
themes remains consistent.
|
||
|
||
The former criterion should be crystal clear as it pertains to the
|
||
scientific foundations of the themes: high legibility and taking care of
|
||
the needs of users with red-green/blue-yellow color deficiency
|
||
(deuteranopia and tritanopia) by avoiding red+green color coding
|
||
paradigms and/or by providing yellow+blue variants for deuteranopia and
|
||
red+cyan for tritanopia (*note Overview::).
|
||
|
||
The latter criterion is the “je ne sais quoi” of the artistic aspect
|
||
of the themes, which is partially fleshed out in this manual.
|
||
|
||
*note Frequently Asked Questions::.
|
||
|
||
With regard to the artistic aspect (where “art” qua skill may amount
|
||
to an imprecise science), there is no hard-and-fast rule in effect as it
|
||
requires one to exercize discretion and make decisions based on
|
||
context-dependent information or constraints. As is true with most
|
||
things in life, when in doubt, do not cling on to the letter of the law
|
||
but try to understand its spirit.
|
||
|
||
For a trivial example: the curly underline that Emacs draws for
|
||
spelling errors is thinner than, e.g., what a graphical web browser has,
|
||
so if I was to design for an editor than has a thicker curly underline I
|
||
would make the applicable colors less intense to counterbalance the
|
||
typographic intensity of the added thickness.
|
||
|
||
With those granted, if anyone is willing to develop a port of the
|
||
themes, they are welcome to contact me and I will do my best to help
|
||
them in their efforts.
|
||
|
||
|
||
File: modus-themes.info, Node: Contributing, Next: Acknowledgements, Prev: Frequently Asked Questions, Up: Top
|
||
|
||
9 Contributing
|
||
**************
|
||
|
||
This section documents the canonical sources of the themes and the ways
|
||
in which you can contribute to their ongoing development.
|
||
|
||
* Menu:
|
||
|
||
* Sources of the themes::
|
||
* Issues you can help with::
|
||
* Patches require copyright assignment to the FSF::
|
||
|
||
|
||
File: modus-themes.info, Node: Sources of the themes, Next: Issues you can help with, Up: Contributing
|
||
|
||
9.1 Sources of the themes
|
||
=========================
|
||
|
||
• Package name (GNU ELPA): ‘modus-themes’
|
||
• Official manual: <https://protesilaos.com/emacs/modus-themes>
|
||
• Change log: <https://protesilaos.com/emacs/modus-themes-changelog>
|
||
• Color palette: <https://protesilaos.com/emacs/modus-themes-colors>
|
||
• Sample pictures:
|
||
<https://protesilaos.com/emacs/modus-themes-pictures>
|
||
• 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>
|
||
• Backronym: My Old Display Unexpectedly Sharpened ... themes
|
||
|
||
|
||
File: modus-themes.info, Node: Issues you can help with, Next: Patches require copyright assignment to the FSF, Prev: Sources of the themes, Up: Contributing
|
||
|
||
9.2 Issues you can help with
|
||
============================
|
||
|
||
A few tasks you can help with by sending an email to the general
|
||
modus-themes public mailing list
|
||
(https://lists.sr.ht/~protesilaos/modus-themes).
|
||
|
||
• Suggest refinements to packages that are covered.
|
||
• Report packages not covered thus far.
|
||
• Report bugs, inconsistencies, shortcomings.
|
||
• Help expand the documentation of covered-but-not-styled packages.
|
||
• Suggest refinements to the color palette.
|
||
• Help expand this document or any other piece of documentation.
|
||
• Send patches for code refinements (if you need, ask me for help
|
||
with Git—we all start out as beginners).
|
||
|
||
*note Patches require copyright assignment to the FSF::.
|
||
|
||
It is preferable that your feedback includes some screenshots, GIFs,
|
||
or short videos, as well as further instructions to reproduce a given
|
||
setup. Though this is not a requirement.
|
||
|
||
Whatever you do, bear in mind the overarching objective of the Modus
|
||
themes: to keep a contrast ratio that is greater or equal to 7:1 between
|
||
background and foreground colors. If a compromise is ever necessary
|
||
between aesthetics and accessibility, it shall always be made in the
|
||
interest of the latter.
|
||
|
||
|
||
File: modus-themes.info, Node: Patches require copyright assignment to the FSF, Prev: Issues you can help with, Up: Contributing
|
||
|
||
9.3 Patches require copyright assignment to the FSF
|
||
===================================================
|
||
|
||
Code contributions are most welcome. For any major edit (more than 15
|
||
lines, or so, in aggregate per person), you need to make a copyright
|
||
assignment to the Free Software Foundation. This is necessary because
|
||
the themes are part of the upstream Emacs distribution: the FSF must at
|
||
all times be in a position to enforce the GNU General Public License.
|
||
|
||
Copyright assignment is a simple process. Check the request form
|
||
below (please adapt it accordingly). You must write an email to the
|
||
address mentioned in the form and then wait for the FSF to send you a
|
||
legal agreement. Sign the document and file it back to them. This
|
||
could all happen via email and take about a week. You are encouraged to
|
||
go through this process. You only need to do it once. It will allow
|
||
you to make contributions to Emacs in general.
|
||
|
||
Please email the following information to assign@gnu.org, and we
|
||
will send you the assignment form for your past and future changes.
|
||
|
||
Please use your full legal name (in ASCII characters) as the subject
|
||
line of the message.
|
||
|
||
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES
|
||
|
||
[What is the name of the program or package you're contributing to?]
|
||
|
||
GNU Emacs
|
||
|
||
[Did you copy any files or text written by someone else in these changes?
|
||
Even if that material is free software, we need to know about it.]
|
||
|
||
Copied a few snippets from the same files I edited. Their author,
|
||
Protesilaos Stavrou, has already assigned copyright to the Free Software
|
||
Foundation.
|
||
|
||
[Do you have an employer who might have a basis to claim to own
|
||
your changes? Do you attend a school which might make such a claim?]
|
||
|
||
|
||
[For the copyright registration, what country are you a citizen of?]
|
||
|
||
|
||
[What year were you born?]
|
||
|
||
|
||
[Please write your email address here.]
|
||
|
||
|
||
[Please write your postal address here.]
|
||
|
||
|
||
|
||
|
||
|
||
[Which files have you changed so far, and which new files have you written
|
||
so far?]
|
||
|
||
|
||
|
||
File: modus-themes.info, Node: Acknowledgements, Next: GNU Free Documentation License, Prev: Contributing, Up: Top
|
||
|
||
10 Acknowledgements
|
||
*******************
|
||
|
||
The Modus themes are a collective effort. Every bit of work matters.
|
||
|
||
Author/maintainer
|
||
Protesilaos Stavrou.
|
||
|
||
Contributions to code or documentation
|
||
Aleksei Gusev, Alex Griffin, Anders Johansson, Antonio Ruiz, Basil
|
||
L. Contovounesios, Björn Lindström, Carlo Zancanaro, Christian
|
||
Tietze, Daniel Mendler, David Edmondson, Eli Zaretskii, Fritz
|
||
Grabo, Gautier Ponsinet, Illia Ostapyshyn, Kévin Le Gouguec, Koen
|
||
van Greevenbroek, Kostadin Ninev, Madhavan Krishnan, Manuel Giraud,
|
||
Markus Beppler, Matthew Stevenson, Mauro Aranda, Nacho Barrientos,
|
||
Nicolas De Jaeghere, Paul David, Philip Kaludercic, Pierre
|
||
Téchoueyres, Rudolf Adamkovič, Sergey Nichiporchik, Shreyas
|
||
Ragavan, Stefan Kangas, Stephen Berman, Stephen Gildea, Steve
|
||
Downey, Tomasz Hołubowicz, Utkarsh Singh, Vincent Murphy, Xinglu
|
||
Chen, Yuanchen Xie, fluentpwn, okamsn.
|
||
|
||
Ideas and user feedback
|
||
Aaron Jensen, Adam Porter, Adam Spiers, Adrian Manea, Aleksei
|
||
Pirogov, Alex Griffin, Alex Koen, Alex Peitsinis, Alexey Shmalko,
|
||
Alok Singh, Anders Johansson, André Alexandre Gomes, Andrew Tropin,
|
||
Antonio Hernández Blas, Arif Rezai, Augusto Stoffel, Basil L.
|
||
Contovounesios, Bernd Rellermeyer, Burgess Chang, Charlotte Van
|
||
Petegem, Christian Tietze, Christopher Dimech, Christopher League,
|
||
Damien Cassou, Daniel Mendler, Dario Gjorgjevski, David Edmondson,
|
||
Davor Rotim, Divan Santana, Eliraz Kedmi, Emanuele Michele Alberto
|
||
Monterosso, Farasha Euker, Feng Shu, Gautier Ponsinet, Gerry
|
||
Agbobada, Gianluca Recchia, Gonçalo Marrafa, Guilherme Semente,
|
||
Gustavo Barros, Hörmetjan Yiltiz, Ilja Kocken, Imran Khan, Iris
|
||
Garcia, Ivan Popovych, James Ferguson, Jeremy Friesen, Jerry Zhang,
|
||
Johannes Grødem, John Haman, Jonas Collberg, Jorge Morais, Joshua
|
||
O’Connor, Julio C. Villasante, Kenta Usami, Kevin Fleming, Kévin
|
||
Le Gouguec, Kevin Kainan Li, Kostadin Ninev, Laith Bahodi, Len
|
||
Trigg, Lennart C. Karssen, Luis Miguel Castañeda, Magne Hov,
|
||
Manuel Giraud, Manuel Uberti, Mark Bestley, Mark Burton, Mark
|
||
Simpson, Marko Kocic, Markus Beppler, Matt Armstrong, Matthias
|
||
Fuchs, Mattias Engdegård, Mauro Aranda, Maxime Tréca, Michael
|
||
Goldenberg, Morgan Smith, Morgan Willcock, Murilo Pereira, Nicky
|
||
van Foreest, Nicolas De Jaeghere, Nicolas Semrau, Olaf Meeuwissen,
|
||
Oliver Epper, Pablo Stafforini, Paul Poloskov, Pengji Zhang, Pete
|
||
Kazmier, Peter Wu, Philip Kaludercic, Pierre Téchoueyres,
|
||
Przemysław Kryger, Robert Hepple, Roman Rudakov, Russell Sim, Ryan
|
||
Phillips, Rytis Paškauskas, Rudolf Adamkovič, Sam Kleinman, Samuel
|
||
Culpepper, Saša Janiška, Shreyas Ragavan, Simon Pugnet, Steve
|
||
Downey, Tassilo Horn, Thanos Apollo, Thibaut Verron, Thomas
|
||
Heartman, Togan Muftuoglu, Tony Zorman, Trey Merkley, Tomasz
|
||
Hołubowicz, Toon Claes, Uri Sharf, Utkarsh Singh, Vincent Foley,
|
||
Zoltan Kiraly. As well as users: Ben, CsBigDataHub1, Emacs
|
||
Contrib, Eugene, Fourchaux, Fredrik, Moesasji, Nick, Summer Emacs,
|
||
TheBlob42, TitusMu, Trey, bepolymathe, bit9tream, bangedorrunt,
|
||
derek-upham, doolio, fleimgruber, gitrj95, iSeeU, jixiuf, okamsn,
|
||
pRot0ta1p, soaringbird, tumashu, wakamenod.
|
||
|
||
Packaging
|
||
Basil L. Contovounesios, Eli Zaretskii, Glenn Morris, Mauro Aranda,
|
||
Richard Stallman, Stefan Kangas (core Emacs), Stefan Monnier (GNU
|
||
Elpa), André Alexandre Gomes, Andrew Tropin, Dimakakos Dimos,
|
||
Morgan Smith, Nicolas Goaziou (Guix), Dhavan Vaidya (Debian).
|
||
|
||
Inspiration for certain features
|
||
Bozhidar Batsov (zenburn-theme), Fabrice Niessen (leuven-theme).
|
||
|
||
Special thanks (from A-Z) to Daniel Mendler, Gustavo Barros, Manuel
|
||
Uberti, Nicolas De Jaeghere, and Omar Antolín Camarena for their long
|
||
time contributions and insightful commentary on key aspects of the
|
||
themes’ design and/or aspects of their functionality.
|
||
|
||
All errors are my own.
|
||
|
||
|
||
File: modus-themes.info, Node: GNU Free Documentation License, Next: Indices, Prev: Acknowledgements, Up: Top
|
||
|
||
Appendix A GNU Free Documentation License
|
||
*****************************************
|
||
|
||
Version 1.3, 3 November 2008
|
||
|
||
Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
|
||
<https://fsf.org/>
|
||
|
||
Everyone is permitted to copy and distribute verbatim copies
|
||
of this license document, but changing it is not allowed.
|
||
|
||
0. PREAMBLE
|
||
|
||
The purpose of this License is to make a manual, textbook, or other
|
||
functional and useful document “free” in the sense of freedom: to
|
||
assure everyone the effective freedom to copy and redistribute it,
|
||
with or without modifying it, either commercially or
|
||
noncommercially. Secondarily, this License preserves for the
|
||
author and publisher a way to get credit for their work, while not
|
||
being considered responsible for modifications made by others.
|
||
|
||
This License is a kind of “copyleft”, which means that derivative
|
||
works of the document must themselves be free in the same sense.
|
||
It complements the GNU General Public License, which is a copyleft
|
||
license designed for free software.
|
||
|
||
We have designed this License in order to use it for manuals for
|
||
free software, because free software needs free documentation: a
|
||
free program should come with manuals providing the same freedoms
|
||
that the software does. But this License is not limited to
|
||
software manuals; it can be used for any textual work, regardless
|
||
of subject matter or whether it is published as a printed book. We
|
||
recommend this License principally for works whose purpose is
|
||
instruction or reference.
|
||
|
||
1. APPLICABILITY AND DEFINITIONS
|
||
|
||
This License applies to any manual or other work, in any medium,
|
||
that contains a notice placed by the copyright holder saying it can
|
||
be distributed under the terms of this License. Such a notice
|
||
grants a world-wide, royalty-free license, unlimited in duration,
|
||
to use that work under the conditions stated herein. The
|
||
“Document”, below, refers to any such manual or work. Any member
|
||
of the public is a licensee, and is addressed as “you”. You accept
|
||
the license if you copy, modify or distribute the work in a way
|
||
requiring permission under copyright law.
|
||
|
||
A “Modified Version” of the Document means any work containing the
|
||
Document or a portion of it, either copied verbatim, or with
|
||
modifications and/or translated into another language.
|
||
|
||
A “Secondary Section” is a named appendix or a front-matter section
|
||
of the Document that deals exclusively with the relationship of the
|
||
publishers or authors of the Document to the Document’s overall
|
||
subject (or to related matters) and contains nothing that could
|
||
fall directly within that overall subject. (Thus, if the Document
|
||
is in part a textbook of mathematics, a Secondary Section may not
|
||
explain any mathematics.) The relationship could be a matter of
|
||
historical connection with the subject or with related matters, or
|
||
of legal, commercial, philosophical, ethical or political position
|
||
regarding them.
|
||
|
||
The “Invariant Sections” are certain Secondary Sections whose
|
||
titles are designated, as being those of Invariant Sections, in the
|
||
notice that says that the Document is released under this License.
|
||
If a section does not fit the above definition of Secondary then it
|
||
is not allowed to be designated as Invariant. The Document may
|
||
contain zero Invariant Sections. If the Document does not identify
|
||
any Invariant Sections then there are none.
|
||
|
||
The “Cover Texts” are certain short passages of text that are
|
||
listed, as Front-Cover Texts or Back-Cover Texts, in the notice
|
||
that says that the Document is released under this License. A
|
||
Front-Cover Text may be at most 5 words, and a Back-Cover Text may
|
||
be at most 25 words.
|
||
|
||
A “Transparent” copy of the Document means a machine-readable copy,
|
||
represented in a format whose specification is available to the
|
||
general public, that is suitable for revising the document
|
||
straightforwardly with generic text editors or (for images composed
|
||
of pixels) generic paint programs or (for drawings) some widely
|
||
available drawing editor, and that is suitable for input to text
|
||
formatters or for automatic translation to a variety of formats
|
||
suitable for input to text formatters. A copy made in an otherwise
|
||
Transparent file format whose markup, or absence of markup, has
|
||
been arranged to thwart or discourage subsequent modification by
|
||
readers is not Transparent. An image format is not Transparent if
|
||
used for any substantial amount of text. A copy that is not
|
||
“Transparent” is called “Opaque”.
|
||
|
||
Examples of suitable formats for Transparent copies include plain
|
||
ASCII without markup, Texinfo input format, LaTeX input format,
|
||
SGML or XML using a publicly available DTD, and standard-conforming
|
||
simple HTML, PostScript or PDF designed for human modification.
|
||
Examples of transparent image formats include PNG, XCF and JPG.
|
||
Opaque formats include proprietary formats that can be read and
|
||
edited only by proprietary word processors, SGML or XML for which
|
||
the DTD and/or processing tools are not generally available, and
|
||
the machine-generated HTML, PostScript or PDF produced by some word
|
||
processors for output purposes only.
|
||
|
||
The “Title Page” means, for a printed book, the title page itself,
|
||
plus such following pages as are needed to hold, legibly, the
|
||
material this License requires to appear in the title page. For
|
||
works in formats which do not have any title page as such, “Title
|
||
Page” means the text near the most prominent appearance of the
|
||
work’s title, preceding the beginning of the body of the text.
|
||
|
||
The “publisher” means any person or entity that distributes copies
|
||
of the Document to the public.
|
||
|
||
A section “Entitled XYZ” means a named subunit of the Document
|
||
whose title either is precisely XYZ or contains XYZ in parentheses
|
||
following text that translates XYZ in another language. (Here XYZ
|
||
stands for a specific section name mentioned below, such as
|
||
“Acknowledgements”, “Dedications”, “Endorsements”, or “History”.)
|
||
To “Preserve the Title” of such a section when you modify the
|
||
Document means that it remains a section “Entitled XYZ” according
|
||
to this definition.
|
||
|
||
The Document may include Warranty Disclaimers next to the notice
|
||
which states that this License applies to the Document. These
|
||
Warranty Disclaimers are considered to be included by reference in
|
||
this License, but only as regards disclaiming warranties: any other
|
||
implication that these Warranty Disclaimers may have is void and
|
||
has no effect on the meaning of this License.
|
||
|
||
2. VERBATIM COPYING
|
||
|
||
You may copy and distribute the Document in any medium, either
|
||
commercially or noncommercially, provided that this License, the
|
||
copyright notices, and the license notice saying this License
|
||
applies to the Document are reproduced in all copies, and that you
|
||
add no other conditions whatsoever to those of this License. You
|
||
may not use technical measures to obstruct or control the reading
|
||
or further copying of the copies you make or distribute. However,
|
||
you may accept compensation in exchange for copies. If you
|
||
distribute a large enough number of copies you must also follow the
|
||
conditions in section 3.
|
||
|
||
You may also lend copies, under the same conditions stated above,
|
||
and you may publicly display copies.
|
||
|
||
3. COPYING IN QUANTITY
|
||
|
||
If you publish printed copies (or copies in media that commonly
|
||
have printed covers) of the Document, numbering more than 100, and
|
||
the Document’s license notice requires Cover Texts, you must
|
||
enclose the copies in covers that carry, clearly and legibly, all
|
||
these Cover Texts: Front-Cover Texts on the front cover, and
|
||
Back-Cover Texts on the back cover. Both covers must also clearly
|
||
and legibly identify you as the publisher of these copies. The
|
||
front cover must present the full title with all words of the title
|
||
equally prominent and visible. You may add other material on the
|
||
covers in addition. Copying with changes limited to the covers, as
|
||
long as they preserve the title of the Document and satisfy these
|
||
conditions, can be treated as verbatim copying in other respects.
|
||
|
||
If the required texts for either cover are too voluminous to fit
|
||
legibly, you should put the first ones listed (as many as fit
|
||
reasonably) on the actual cover, and continue the rest onto
|
||
adjacent pages.
|
||
|
||
If you publish or distribute Opaque copies of the Document
|
||
numbering more than 100, you must either include a machine-readable
|
||
Transparent copy along with each Opaque copy, or state in or with
|
||
each Opaque copy a computer-network location from which the general
|
||
network-using public has access to download using public-standard
|
||
network protocols a complete Transparent copy of the Document, free
|
||
of added material. If you use the latter option, you must take
|
||
reasonably prudent steps, when you begin distribution of Opaque
|
||
copies in quantity, to ensure that this Transparent copy will
|
||
remain thus accessible at the stated location until at least one
|
||
year after the last time you distribute an Opaque copy (directly or
|
||
through your agents or retailers) of that edition to the public.
|
||
|
||
It is requested, but not required, that you contact the authors of
|
||
the Document well before redistributing any large number of copies,
|
||
to give them a chance to provide you with an updated version of the
|
||
Document.
|
||
|
||
4. MODIFICATIONS
|
||
|
||
You may copy and distribute a Modified Version of the Document
|
||
under the conditions of sections 2 and 3 above, provided that you
|
||
release the Modified Version under precisely this License, with the
|
||
Modified Version filling the role of the Document, thus licensing
|
||
distribution and modification of the Modified Version to whoever
|
||
possesses a copy of it. In addition, you must do these things in
|
||
the Modified Version:
|
||
|
||
A. Use in the Title Page (and on the covers, if any) a title
|
||
distinct from that of the Document, and from those of previous
|
||
versions (which should, if there were any, be listed in the
|
||
History section of the Document). You may use the same title
|
||
as a previous version if the original publisher of that
|
||
version gives permission.
|
||
|
||
B. List on the Title Page, as authors, one or more persons or
|
||
entities responsible for authorship of the modifications in
|
||
the Modified Version, together with at least five of the
|
||
principal authors of the Document (all of its principal
|
||
authors, if it has fewer than five), unless they release you
|
||
from this requirement.
|
||
|
||
C. State on the Title page the name of the publisher of the
|
||
Modified Version, as the publisher.
|
||
|
||
D. Preserve all the copyright notices of the Document.
|
||
|
||
E. Add an appropriate copyright notice for your modifications
|
||
adjacent to the other copyright notices.
|
||
|
||
F. Include, immediately after the copyright notices, a license
|
||
notice giving the public permission to use the Modified
|
||
Version under the terms of this License, in the form shown in
|
||
the Addendum below.
|
||
|
||
G. Preserve in that license notice the full lists of Invariant
|
||
Sections and required Cover Texts given in the Document’s
|
||
license notice.
|
||
|
||
H. Include an unaltered copy of this License.
|
||
|
||
I. Preserve the section Entitled “History”, Preserve its Title,
|
||
and add to it an item stating at least the title, year, new
|
||
authors, and publisher of the Modified Version as given on the
|
||
Title Page. If there is no section Entitled “History” in the
|
||
Document, create one stating the title, year, authors, and
|
||
publisher of the Document as given on its Title Page, then add
|
||
an item describing the Modified Version as stated in the
|
||
previous sentence.
|
||
|
||
J. Preserve the network location, if any, given in the Document
|
||
for public access to a Transparent copy of the Document, and
|
||
likewise the network locations given in the Document for
|
||
previous versions it was based on. These may be placed in the
|
||
“History” section. You may omit a network location for a work
|
||
that was published at least four years before the Document
|
||
itself, or if the original publisher of the version it refers
|
||
to gives permission.
|
||
|
||
K. For any section Entitled “Acknowledgements” or “Dedications”,
|
||
Preserve the Title of the section, and preserve in the section
|
||
all the substance and tone of each of the contributor
|
||
acknowledgements and/or dedications given therein.
|
||
|
||
L. Preserve all the Invariant Sections of the Document, unaltered
|
||
in their text and in their titles. Section numbers or the
|
||
equivalent are not considered part of the section titles.
|
||
|
||
M. Delete any section Entitled “Endorsements”. Such a section
|
||
may not be included in the Modified Version.
|
||
|
||
N. Do not retitle any existing section to be Entitled
|
||
“Endorsements” or to conflict in title with any Invariant
|
||
Section.
|
||
|
||
O. Preserve any Warranty Disclaimers.
|
||
|
||
If the Modified Version includes new front-matter sections or
|
||
appendices that qualify as Secondary Sections and contain no
|
||
material copied from the Document, you may at your option designate
|
||
some or all of these sections as invariant. To do this, add their
|
||
titles to the list of Invariant Sections in the Modified Version’s
|
||
license notice. These titles must be distinct from any other
|
||
section titles.
|
||
|
||
You may add a section Entitled “Endorsements”, provided it contains
|
||
nothing but endorsements of your Modified Version by various
|
||
parties—for example, statements of peer review or that the text has
|
||
been approved by an organization as the authoritative definition of
|
||
a standard.
|
||
|
||
You may add a passage of up to five words as a Front-Cover Text,
|
||
and a passage of up to 25 words as a Back-Cover Text, to the end of
|
||
the list of Cover Texts in the Modified Version. Only one passage
|
||
of Front-Cover Text and one of Back-Cover Text may be added by (or
|
||
through arrangements made by) any one entity. If the Document
|
||
already includes a cover text for the same cover, previously added
|
||
by you or by arrangement made by the same entity you are acting on
|
||
behalf of, you may not add another; but you may replace the old
|
||
one, on explicit permission from the previous publisher that added
|
||
the old one.
|
||
|
||
The author(s) and publisher(s) of the Document do not by this
|
||
License give permission to use their names for publicity for or to
|
||
assert or imply endorsement of any Modified Version.
|
||
|
||
5. COMBINING DOCUMENTS
|
||
|
||
You may combine the Document with other documents released under
|
||
this License, under the terms defined in section 4 above for
|
||
modified versions, provided that you include in the combination all
|
||
of the Invariant Sections of all of the original documents,
|
||
unmodified, and list them all as Invariant Sections of your
|
||
combined work in its license notice, and that you preserve all
|
||
their Warranty Disclaimers.
|
||
|
||
The combined work need only contain one copy of this License, and
|
||
multiple identical Invariant Sections may be replaced with a single
|
||
copy. If there are multiple Invariant Sections with the same name
|
||
but different contents, make the title of each such section unique
|
||
by adding at the end of it, in parentheses, the name of the
|
||
original author or publisher of that section if known, or else a
|
||
unique number. Make the same adjustment to the section titles in
|
||
the list of Invariant Sections in the license notice of the
|
||
combined work.
|
||
|
||
In the combination, you must combine any sections Entitled
|
||
“History” in the various original documents, forming one section
|
||
Entitled “History”; likewise combine any sections Entitled
|
||
“Acknowledgements”, and any sections Entitled “Dedications”. You
|
||
must delete all sections Entitled “Endorsements.”
|
||
|
||
6. COLLECTIONS OF DOCUMENTS
|
||
|
||
You may make a collection consisting of the Document and other
|
||
documents released under this License, and replace the individual
|
||
copies of this License in the various documents with a single copy
|
||
that is included in the collection, provided that you follow the
|
||
rules of this License for verbatim copying of each of the documents
|
||
in all other respects.
|
||
|
||
You may extract a single document from such a collection, and
|
||
distribute it individually under this License, provided you insert
|
||
a copy of this License into the extracted document, and follow this
|
||
License in all other respects regarding verbatim copying of that
|
||
document.
|
||
|
||
7. AGGREGATION WITH INDEPENDENT WORKS
|
||
|
||
A compilation of the Document or its derivatives with other
|
||
separate and independent documents or works, in or on a volume of a
|
||
storage or distribution medium, is called an “aggregate” if the
|
||
copyright resulting from the compilation is not used to limit the
|
||
legal rights of the compilation’s users beyond what the individual
|
||
works permit. When the Document is included in an aggregate, this
|
||
License does not apply to the other works in the aggregate which
|
||
are not themselves derivative works of the Document.
|
||
|
||
If the Cover Text requirement of section 3 is applicable to these
|
||
copies of the Document, then if the Document is less than one half
|
||
of the entire aggregate, the Document’s Cover Texts may be placed
|
||
on covers that bracket the Document within the aggregate, or the
|
||
electronic equivalent of covers if the Document is in electronic
|
||
form. Otherwise they must appear on printed covers that bracket
|
||
the whole aggregate.
|
||
|
||
8. TRANSLATION
|
||
|
||
Translation is considered a kind of modification, so you may
|
||
distribute translations of the Document under the terms of section
|
||
4. Replacing Invariant Sections with translations requires special
|
||
permission from their copyright holders, but you may include
|
||
translations of some or all Invariant Sections in addition to the
|
||
original versions of these Invariant Sections. You may include a
|
||
translation of this License, and all the license notices in the
|
||
Document, and any Warranty Disclaimers, provided that you also
|
||
include the original English version of this License and the
|
||
original versions of those notices and disclaimers. In case of a
|
||
disagreement between the translation and the original version of
|
||
this License or a notice or disclaimer, the original version will
|
||
prevail.
|
||
|
||
If a section in the Document is Entitled “Acknowledgements”,
|
||
“Dedications”, or “History”, the requirement (section 4) to
|
||
Preserve its Title (section 1) will typically require changing the
|
||
actual title.
|
||
|
||
9. TERMINATION
|
||
|
||
You may not copy, modify, sublicense, or distribute the Document
|
||
except as expressly provided under this License. Any attempt
|
||
otherwise to copy, modify, sublicense, or distribute it is void,
|
||
and will automatically terminate your rights under this License.
|
||
|
||
However, if you cease all violation of this License, then your
|
||
license from a particular copyright holder is reinstated (a)
|
||
provisionally, unless and until the copyright holder explicitly and
|
||
finally terminates your license, and (b) permanently, if the
|
||
copyright holder fails to notify you of the violation by some
|
||
reasonable means prior to 60 days after the cessation.
|
||
|
||
Moreover, your license from a particular copyright holder is
|
||
reinstated permanently if the copyright holder notifies you of the
|
||
violation by some reasonable means, this is the first time you have
|
||
received notice of violation of this License (for any work) from
|
||
that copyright holder, and you cure the violation prior to 30 days
|
||
after your receipt of the notice.
|
||
|
||
Termination of your rights under this section does not terminate
|
||
the licenses of parties who have received copies or rights from you
|
||
under this License. If your rights have been terminated and not
|
||
permanently reinstated, receipt of a copy of some or all of the
|
||
same material does not give you any rights to use it.
|
||
|
||
10. FUTURE REVISIONS OF THIS LICENSE
|
||
|
||
The Free Software Foundation may publish new, revised versions of
|
||
the GNU Free Documentation License from time to time. Such new
|
||
versions will be similar in spirit to the present version, but may
|
||
differ in detail to address new problems or concerns. See
|
||
<https://www.gnu.org/licenses/>.
|
||
|
||
Each version of the License is given a distinguishing version
|
||
number. If the Document specifies that a particular numbered
|
||
version of this License “or any later version” applies to it, you
|
||
have the option of following the terms and conditions either of
|
||
that specified version or of any later version that has been
|
||
published (not as a draft) by the Free Software Foundation. If the
|
||
Document does not specify a version number of this License, you may
|
||
choose any version ever published (not as a draft) by the Free
|
||
Software Foundation. If the Document specifies that a proxy can
|
||
decide which future versions of this License can be used, that
|
||
proxy’s public statement of acceptance of a version permanently
|
||
authorizes you to choose that version for the Document.
|
||
|
||
11. RELICENSING
|
||
|
||
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any
|
||
World Wide Web server that publishes copyrightable works and also
|
||
provides prominent facilities for anybody to edit those works. A
|
||
public wiki that anybody can edit is an example of such a server.
|
||
A “Massive Multiauthor Collaboration” (or “MMC”) contained in the
|
||
site means any set of copyrightable works thus published on the MMC
|
||
site.
|
||
|
||
“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0
|
||
license published by Creative Commons Corporation, a not-for-profit
|
||
corporation with a principal place of business in San Francisco,
|
||
California, as well as future copyleft versions of that license
|
||
published by that same organization.
|
||
|
||
“Incorporate” means to publish or republish a Document, in whole or
|
||
in part, as part of another Document.
|
||
|
||
An MMC is “eligible for relicensing” if it is licensed under this
|
||
License, and if all works that were first published under this
|
||
License somewhere other than this MMC, and subsequently
|
||
incorporated in whole or in part into the MMC, (1) had no cover
|
||
texts or invariant sections, and (2) were thus incorporated prior
|
||
to November 1, 2008.
|
||
|
||
The operator of an MMC Site may republish an MMC contained in the
|
||
site under CC-BY-SA on the same site at any time before August 1,
|
||
2009, provided the MMC is eligible for relicensing.
|
||
|
||
ADDENDUM: How to use this License for your documents
|
||
====================================================
|
||
|
||
To use this License in a document you have written, include a copy of
|
||
the License in the document and put the following copyright and license
|
||
notices just after the title page:
|
||
|
||
Copyright (C) YEAR YOUR NAME.
|
||
Permission is granted to copy, distribute and/or modify this document
|
||
under the terms of the GNU Free Documentation License, Version 1.3
|
||
or any later version published by the Free Software Foundation;
|
||
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
|
||
Texts. A copy of the license is included in the section entitled ``GNU
|
||
Free Documentation License''.
|
||
|
||
If you have Invariant Sections, Front-Cover Texts and Back-Cover
|
||
Texts, replace the “with...Texts.” line with this:
|
||
|
||
with the Invariant Sections being LIST THEIR TITLES, with
|
||
the Front-Cover Texts being LIST, and with the Back-Cover Texts
|
||
being LIST.
|
||
|
||
If you have Invariant Sections without Cover Texts, or some other
|
||
combination of the three, merge those two alternatives to suit the
|
||
situation.
|
||
|
||
If your document contains nontrivial examples of program code, we
|
||
recommend releasing these examples in parallel under your choice of free
|
||
software license, such as the GNU General Public License, to permit
|
||
their use in free software.
|
||
|
||
|
||
File: modus-themes.info, Node: Indices, Prev: GNU Free Documentation License, Up: Top
|
||
|
||
B Indices
|
||
*********
|
||
|
||
* Menu:
|
||
|
||
* Function index::
|
||
* Variable index::
|
||
* Concept index::
|
||
|
||
|
||
File: modus-themes.info, Node: Function index, Next: Variable index, Up: Indices
|
||
|
||
B.1 Function index
|
||
==================
|
||
|
||
|