The user can thus override the 'fringe' mapping to whatever colour
they prefer, instead of us hardcoding it to two shades of gray.
To make the 'fringe' invisible, set it to the main background.
Video tutorial on colour mappings:
<https://protesilaos.com/codelog/2022-12-17-modus-themes-v4-demo/>.
Providing bespoke themes gives us the freedom to implement changes
wherever necessary without making the code more complex. The now
discontinued 'modus-themes-deuteranopia' was a user option with
limited scope: it simply replaced green with blue in some contexts.
But a proper design for deuteranopia requires more than that. These
new themes are the right solution and I am sure the people who need
them will greatly appreciate them.
You can play around with the following, changing "bg-cyan" to one of
bg-{red,green,yellow,blue,magenta}.
(setopt modus-themes-to-toggle '(modus-operandi modus-operandi-tinted))
(setopt modus-themes-to-toggle '(modus-vivendi modus-vivendi-tinted))
(setq modus-operandi-palette-overrides '((bg-mode-line-active bg-cyan))
modus-operandi-tinted-palette-overrides modus-operandi-palette-overrides
modus-vivendi-palette-overrides modus-operandi-palette-overrides
modus-vivendi-tinted-palette-overrides modus-operandi-palette-overrides)
The user has the option to override the bg-completion colour, which
gives them all they need. I had already deprecated the "intense"
style earlier, though not from the docs.
Version 4 of the modus-themes is abstracting each theme's palette,
introduces semantic colour mappings, and expands the scope of the
palette overrides. I am removing user options, but am actually giving
user more power over how to tweak the theme. Overview:
<https://protesilaos.com/codelog/2022-12-07-modus-themes-4-colour-values-mappings/>.
As this diff demonstrates, we remove a lot of the complexity from the
themes.
I had removed it from the modus-themes.el as part of the refactoring
that (i) simplifies the main file, and (ii) introduces colour mapping
to each theme's palette.
The colour palettes are now defined in the individual themes. This
means that we can, in principle, introduce more themes without ever
expanding modus-themes.el (the user can also register their own Modus
theme variant, which we will eventually document in the manual).
The purpose of this refactoring is to improve the code, but otherwise
retain the themes' character. There will still be some changes,
though those will be barely noticeable unless a side-by-side
comparison is performed.
The intent is three-fold:
* Reduce the number of entries, which makes things easier to maintain,
extend, configure.
* Introduce colour mappings, which allow us to optimise each theme
when necessary. For example, the mail-3 mapping is not shared
between the two themes, simply because another hue is more
appropriate. There may be more such cases in the future.
* Make the palette easier to understand by using more meaningful names
and colour associations. This will eventually help us use the
modus-themes.el as a basis for more themes.
The intent is to reduce the number of possible combinations and,
generally, make it easier to maintain the themes. Furthermore, some
of those combinations were simply not good enough.
This reverts commit f1cf9a1eb2.
The report in issue 50 on the GitHub mirror made me think that we
should not do this as it is backward incompatible:
<https://github.com/protesilaos/modus-themes/issues/50>.
Besides, the files already include theme properties in a different
way, per commit 5fee337.
This reverts commit 3d6221e284. Upon
further inspection, the issue is specific to Emacs 29. I tried to build
the package with Emacs 27, 28, 29, and only the latter produces the
error.
Commit f067d2e explains at length the rationale for wrapping the
reification of the themes in 'eval-and-compile'. While that appears to
solve the problem documented therein, it creates a new one: when we try
to byte compile a theme, we get:
Error: Lisp nesting exceeds ‘max-lisp-eval-depth’
I think byte compilation is nice to have, but it keeps giving us
problems. I am thus disabling it until further notice.
[ Themes shipped with Emacs are not byte compiled (includes
modus-operandi and modus-vivendi). I have seen third-party themes do
the same, such as Bozhidar Batsov's zenburn. ]
Thanks to Omar Antolín Camarena (@oantolin) for reporting the
aforementioned error.
This is an attempt to fix a bug that has existed since version 1.2.0 of
the themes or even earlier.
The bug is about a mismatch between compiled code and runtime
dependencies. The runtime expects the current version while the
compiled code only furnishes an outdated one, thus resulting in an
error. This only happens when:
1. Private functions change to accept more/fewer arguments.
2. Variables change their acceptable value (e.g. from symbol to list).
3. The user is installing the package via the package.el mechanism which
takes care of byte compilation (though anything that mimics
package.el should exhibit the same behaviour).
My understanding is that the cause was the limited scope of the
'eval-and-compile' we had before: it would run the 'require' also at
compile time, whereas the 'modus-themes-theme' macro, which reifies the
actual theme, would only be evaluated at runtime. Hence the mismatch as
'require' would read the already installed byte code while the macro
would expect newer forms.
Wrapping everything in the 'eval-and-compile' should address this
problem. Hopefully it will not engender new ones...
* * *
The latest reports about this bug:
* GitLab issue 287 with Mark Bestley and Daniel Mendler:
<https://gitlab.com/protesilaos/modus-themes/-/issues/287>.
* GitHub issue 22 with Rytis Paškauskas:
<https://github.com/protesilaos/modus-themes/issues/22>.
The main file, modus-themes.el, has had this minimum requirement on
Emacs 27.1 for a while now.
Thanks to Togan Muftuoglu for reporting the inconsistency in issue 246:
<https://gitlab.com/protesilaos/modus-themes/-/issues/246>.
This is related to issue 164, which pertains to a problem in byte
compilation that is experienced while using 'straight.el' on Emacs 28:
<https://gitlab.com/protesilaos/modus-themes/-/issues/164>.
Thanks, in no particular order, to everyone who has participated thus
far in that thread: John Haman, Trey, Nicolas De Jaeghere, Mauro Aranda.
This snippet is courtesy of Basil L. Contovounesios. It is meant to
make the themes load their main library regardless of version or setup,
as discussed in issue 162:
<https://gitlab.com/protesilaos/modus-themes/-/issues/162>.
The themes are already in Emacs, but we have to use a new function for
things to work as intended with the new version of the files (check the
Emacs source code for the technicalities of 'require-theme').
This is in preparation of the imminent release of version 1.2.0.
Minor tweaks to the manual to ensure that the right instructions are
provided for those who install the themes manually or will be using the
version that is shipped with Emacs.
* modus-operandi-theme.el (modus-themes, require): Just require
'modus-themes is enough. No need for eval-and-compile.
* modus-vivendi-theme.el (modus-themes, require): Same.
Evaluate this:
(info "(elisp) Compiling Macros")
Byte-compiling a file also executes any ‘require’ calls at top-level
in the file, so you can ensure that necessary macro definitions are
available during compilation by requiring the files that define
them (*note Named Features::). To avoid loading the macro
definition files when someone _runs_ the compiled program, write
‘eval-when-compile’ around the ‘require’ calls (*note Eval During
Compile::).
