Refactor Modus Themes (plan for version 1.0.0)

The problem with the current code

We have had some major problems with the byte compiled version of the themes. See, in particular, issue 102 and issue 109.

I have temporarily disabled byte compilation, but I do not like that.

In short, there currently is some faulty code that defines a macro and then expands it inside the same file. What that macro tries to do is two-fold:

  1. Expand the alist of the main colour palette as a series of local variables bound to face specs with let.

  2. Pass a second alist with user-defined colour associations. Those are meant to override existing ones in the palette or create new ones.

Because the macro and its expansion are defined in the same file, byte compilation can never work (if my reading of all the docs is correct).

For the macro to work as intended, it needs to be defined in one file and then be required in the other where its expansion takes place.

Doing so should eliminate both of the aforementioned issues. My tests suggest that this is the case.

Other considerations

I was already keen on unifying and rationalising the two themes. Also refer to issue 82. The idea is to provide a uniform interface for their customisations, probably a single package that contains both Modus Operandi and Modus Vivendi, as well as whatever extras we may consider necessary (e.g. a toggle function that switches from light to dark).

We are thus presented with a unique opportunity to tackle the bugs with the macro and also provide the requisite level of uniformity.

The current plan

The plan to release version 0.14.0 in mid-November is cancelled. The next release will be version 1.0.0, whenever it is ready. To that end, a new project is set up: https://gitlab.com/protesilaos/modus-themes-refactor.

Objectives of the new project:

  • Ensure that all macros are defined and expanded the right number of times and that evaluation takes place at the right moment.

  • Guarantee that colour palette overrides work with the byte compiled code. Disabling byte compilation is a dirty hack that I do not want to keep around. We do not want to sacrifice performance.

  • Abstract face specs so as to avoid duplication of efforts.

  • Provide mechanisms for differentiating between the themes when/where necessary.

  • Offer two levels of customisation options. One that covers both themes. Another that is specific to each of them.

  • Determine how conflicts between such options should be handled. Those with more specificity should take precedence, but we need to see how this is done in terms of its implementation.

  • Identify all packaging-related implications and take the necessary measures to avoid breakage in existing setups.

  • Anything else?

Your feedback and contributions in this endeavour are much appreciated. I will be iterating on that project and keep this issue up-to-date with reports about my progress.

Note that I have never done anything like this before and am developing expertise as I go. If you see some error or a needlessly complex routine in my code, do not hesitate to inform me about it.