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::).
