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, 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
|
|||
|
==================
|
|||
|
|
|||
|
|