Re: Add four new Modus themes to Emacs?

[Protesilaos Stavrou <info@protesilaos.com>]

> From: Philip Kaludercic <philipk@posteo.net>
> Date: Mon, 19 Dec 2022 15:53:26 +0000

> [... 16 lines elided]

>> All new themes are consistent with the WCAG AAA accessibility standard
>> for colour contrast.
>>
>> Should these four new themes be added to emacs.git when I release
>> version-4?  Or should I just update only 'modus-operandi' and
>> 'modus-vivendi'?
>
> My main worry is that the default theme options could get too crowded.
> Then again, if we want to keep deuteranopia support, the two new
> variants will have to be added... (On that topic, I still think that the
> approach I suggested earlier this year would be preferable: Instead of a
> separate theme or multiple options, we just need to describe the
> transformations that maximise the volume of the original colour space
> within the boundaries of whatever is permissible for each kind of colour
> deficiency).

If there is such a transformation, I am happy to use it or, anyhow,
adapt accordingly.

With this new design, an extra theme is easy to develop and I can
exercise full control over its colour values.  The palette overrides the
themes provides make it particularly helpful for users who need specific
colour values.  I have received feedback from people who have various
degrees of deuteranomaly (not deuteranopia) and they all required
case-specific tweaks.  With the way I have it now in version-4, I can
tend to their needs on a case-by-case basis.

> The alternative is having the base themes in Emacs, and if anyone wants
> more then they would have to download the themes from ELPA, right?

Yes, that is an option.  The recipe in elpa.git will need to be updated,
as it was written before the :auto-sync and GNU-devel ELPA were
available.

>> My plan is to finalise version-4 by the end of this month.  It contains
>> lots of changes.
>
> This might be a bit late, but I think that you were a bit too quick in
> deprecating a lot of the user option, while also dropping backwards
> compatibility.  Usually, an option is deprecated and users are given
> hints what they have to do in the future, but everything will continue
> working for now.  When I recently installed version-4, I noticed that a
> number of things changed and I wasn't sure where to look to fix these
> issues.  Now of course, this is just a visual theme and nothing about
> Emacs breaks functionality-wise, but it would still be nice to have a
> shim for now that translates old user options into the new configuration
> pattern.

I did that before and it kept us on the path dependency of old design
decisions that could not accommodate new ideas.  This resulted in code
complexity that was difficult to maintain.  Ultimately though, it was
inflexible.  The trick part with accessibility is that it cannot be a
one-size-fits-all even though some guidelines are acceptable.

My plan for the coming days is to document everything and provide
detailed instructions on how to configure things.  I will also write
articles leading up to the release to demonstrate specific scenaria.

If I need to delay the release, I will.

-- 
Protesilaos Stavrou
https://protesilaos.com