Re: "modern" colors Re: Changes for emacs 28

[Arthur Miller <arthur.miller@live.com>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > It would make Emacs look more aesthetically pleasing if packages output 
>   > > data in more color consistent and coherent  way instead of everyone 
>   > > sprinkling hardcoded RGB values for their outputs.
>
>   > Yup. It sounds like a big change, though.
>
> A small part of Emacs interprets color specifications.
> If we want to define a new kind of color specification,
> perhaps defined in terms of solarized, it whould not be hard.
>

I was thinking about it a bit, and was looking at the code of Bozhidar's
Solarized implementation. I think it is rather a trivial thing to do.

Here is what I think is a specific of Emacs: 

1. Emacs has not parametrized names for colors of standard GUI elements
(as I am aware of); so both Emacs internally, and third party packages
are using color values directly for GUI elements (variables like
forground, background etc). It results in Emacs theme having to go to
great deal of color customizations when it comes to third party packages
in particular. For illustration take at look at

https://github.com/bbatsov/solarized-emacs/blob/master/solarized-faces.el

Or themes don't do this which results in less coherent visual appereance
in the end.

2. Everything in Emacs is text (mostly); that is one of best features of
Emacs but it also means that pretty much any defvar can become a part of
gui which leads to third party packages using color values directly (or
none). It makes it hard for themes to create unified looks in Emacs for all the
diverse packages that are out there.

What is nice with original Solarized by Ethan S. is that there is
"logical framework" to think about colors: he defines base colors
(background, foreground, selection etc) and accented colors for
information that has to stand out. Bozhidar's implementation adds ligher
and darker variant to accented colors. But best part with Bozhidar's
Solarized for Emacs is that he has done a lion share of work on styling
thrid party packages:

https://github.com/bbatsov/solarized-emacs/blob/master/solarized-faces.el

to make them consistent Emacs GUI and Solarized theme.

I think his theme implementation can be simplified, paramtrized and
turned into relatively simple framework to use.

For end users who would like to create a color scheme it could be as
easy as just specifying a two arrays of colors, base and accented ones.
For package creators, elisp scripting etc, it could be relatively simply
to use paramerized names like cs-accent-1, cs-accent-darker-1 etc (cs =
color-scheme), or something similar. It shouldn't be hard to write a
manual/docs on how to use the framework either since it is pretty much
trivial.

I can try to refactor Bozhidar's code if it is interesting (I have been
playing with it for my own purpose soem time ago), if Bozhidar himself is
not reading this list and don't' have opinions on this by himself.

> The hard question is what we WANT to do.  Does someone want to
> study the details and make a concrete proposal?

Concrete proposal would be:

1. remove dark/light variant and some color blending code which is
specific for Solarized theme itself to simplify the framework. 

2. parametrize names, instead of yellow, magenta etc, use something like
cs-accent-1, cs-accent-2, cs-base-1, cs-base-2 etc

3. create setter/getter api to manipulate base/accent color arrays
4. write nice docs/tips/guide how to use it