solarized

solarized

[Richard Stallman]

[[[ 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. ]]]

I looked at the web page about Solarized.  It sounds interesting,
but I wonder what it looks like.  Can anyone tell me how to see
those colors in some text?  (Any text.)

What I read seemed to say that Solarized is a color palette,
and there are many ways to use it.  I'd like to see the palette.
Emacs's predefined faces amount to a color palette.
I wonder if using Solarized colors for them could be an improvement.
A priori, that may or may not be so.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: solarized

[Protesilaos Stavrou]

[-- Attachment #1: Type: text/plain, Size: 3608 bytes --]

Hello Richard,

Richard Stallman <rms@gnu.org> [2020-09-13, 23:48 -0400]:

> I looked at the web page about Solarized.  It sounds interesting,
> but I wonder what it looks like.  Can anyone tell me how to see
> those colors in some text?  (Any text.)

Please see attached screenshots for solarized-light and solarized-dark
respectively.  Just a hint at what to expect on an 'emacs -Q' plus the
loaded theme.

> What I read seemed to say that Solarized is a color palette,
> and there are many ways to use it.  I'd like to see the palette.
> Emacs's predefined faces amount to a color palette.
> I wonder if using Solarized colors for them could be an improvement.
> A priori, that may or may not be so.

Solarized is one of the best colour palettes in terms of what it tried
to achieve, namely, a 16-colour palette that adapts to light and dark
variations and which strives for a fairly consistent level of luminance.

My opinion is that Emacs' default faces should be designed with
accessibility (readability) in mind.  A minimum contrast ratio of 4.5:1
between a given foreground and background combination ensures that Emacs
will be readable out-of-the-box for the majority of people.  If you want
to be even more inclusive, a minimum 7:1 contrast ratio is recommended.

Solarized fails on the accessibility front (not its designer's fault, as
that was not its goal).  Many colour combinations are well below the
minimum 4.5:1 threshold.  The following table shows the relative
luminance of all colours of the palette compared with the four base
background values (table's image with colour previews also attached).

| SOLARIZED | HEX     | #002b36 | #073642 | #eee8d5 | #fdf6e3 |
|-----------+---------+---------+---------+---------+---------|
| base03    | #002b36 |    1.00 |    1.15 |   12.25 |   13.92 |
| base02    | #073642 |    1.15 |    1.00 |   10.61 |   12.05 |
| base01    | #586e75 |    2.79 |    2.42 |    4.39 |    4.99 |
| base00    | #657b83 |    3.37 |    2.92 |    3.64 |    4.13 |
| base0     | #839496 |    4.75 |    4.11 |    2.58 |    2.93 |
| base1     | #93a1a1 |    5.61 |    4.86 |    2.18 |    2.48 |
| base2     | #eee8d5 |   12.25 |   10.61 |    1.00 |    1.14 |
| base3     | #fdf6e3 |   13.92 |   12.05 |    1.14 |    1.00 |
| yellow    | #b58900 |    4.68 |    4.05 |    2.62 |    2.98 |
| orange    | #cb4b16 |    3.26 |    2.82 |    3.76 |    4.27 |
| red       | #dc322f |    3.25 |    2.81 |    3.77 |    4.29 |
| magenta   | #d33682 |    3.30 |    2.86 |    3.71 |    4.21 |
| violet    | #6c71c4 |    3.43 |    2.97 |    3.57 |    4.06 |
| blue      | #268bd2 |    4.08 |    3.53 |    3.00 |    3.41 |
| cyan      | #2aa198 |    4.75 |    4.12 |    2.58 |    2.93 |
| green     | #859900 |    4.69 |    4.06 |    2.62 |    2.97 |

Please refer to this spec for the technical details of the formula that
tests for compliance with the WCAG standard for colour contrast:
<https://www.w3.org/TR/WCAG20-TECHS/G18.html>.

That granted, Solarized would make for a good basis to build derivative
works off of.  My comment concerns the overall framework or set of
guidelines that should inform the choice of colours and design overall.

For an alternative that conforms with the WCAG AAA standard (7:1), has
broad face/package coverage, and is highly customisable, consider either
of the themes 'modus-operandi' (light) and 'modus-vivendi' (dark) which
are in the Emacs master branch.  Disclosure: I am their author and will
share their latest version, as well as an Info manual, at the end of
this month.

Best regards,
Protesilaos

-- 
Protesilaos Stavrou
protesilaos.com


[-- Attachment #2: solarized-dark.png --]
[-- Type: image/png, Size: 181266 bytes --]

[-- Attachment #3: solarized-light.png --]
[-- Type: image/png, Size: 180093 bytes --]

[-- Attachment #4: solarized-wcag-table.png --]
[-- Type: image/png, Size: 190258 bytes --]

Re: solarized

[Yuri Khan]

On Tue, 15 Sep 2020 at 15:44, Protesilaos Stavrou <info@protesilaos.com> wrote:

> Solarized fails on the accessibility front (not its designer's fault, as
> that was not its goal).  Many colour combinations are well below the
> minimum 4.5:1 threshold.  The following table shows the relative
> luminance of all colours of the palette compared with the four base
> background values (table's image with colour previews also attached).

A color theme does not have to provide 4.5:1 contrast for each-to-each
color combination. Only for those that are actually used to display
text.

The important ones are:

* base dark colors against base lightest color
* base light colors against base darkest color
* accent colors against base lightest and base darkest colors

Slightly less important:

* base dark colors against base second-lightest color
* base light colors against base second-darkest color
* accent colors against base second-lightest and second-darkest

> | SOLARIZED | HEX     | #002b36 | #073642 | #eee8d5 | #fdf6e3 |
> |-----------+---------+---------+---------+---------+---------|
> | base03    | #002b36 |         |         |   12.25 |   13.92 |
> | base02    | #073642 |         |         |   10.61 |   12.05 |
> | base01    | #586e75 |         |         |    4.39 |    4.99 |
> | base00    | #657b83 |         |         |    3.64 |    4.13 |
> | base0     | #839496 |    4.75 |    4.11 |         |         |
> | base1     | #93a1a1 |    5.61 |    4.86 |         |         |
> | base2     | #eee8d5 |   12.25 |   10.61 |         |         |
> | base3     | #fdf6e3 |   13.92 |   12.05 |         |         |
> | yellow    | #b58900 |    4.68 |    4.05 |    2.62 |    2.98 |
> | orange    | #cb4b16 |    3.26 |    2.82 |    3.76 |    4.27 |
> | red       | #dc322f |    3.25 |    2.81 |    3.77 |    4.29 |
> | magenta   | #d33682 |    3.30 |    2.86 |    3.71 |    4.21 |
> | violet    | #6c71c4 |    3.43 |    2.97 |    3.57 |    4.06 |
> | blue      | #268bd2 |    4.08 |    3.53 |    3.00 |    3.41 |
> | cyan      | #2aa198 |    4.75 |    4.12 |    2.58 |    2.93 |
> | green     | #859900 |    4.69 |    4.06 |    2.62 |    2.97 |

Also, Solarized picked a design decision of using the same accent
colors against dark and light backgrounds. This makes it hard to
satisfy the 4.5:1 requirement, because if accent is at least 4.5:1 to
darkest and lightest is at least 4.5:1 to accent, then lightest must
be at least 20.25:1 to darkest, and the chosen Solarized lightest and
darkest do not satisfy that. So, within the given limitations,
Solarized does well enough.

(Disclosure: Personally, I do not like or use Solarized, because of
its heavy tinting of the light background to yellow. Light backgrounds
are supposed to resemble paper, and yellowish paper looks cheap and/or
old to me.)

Re: solarized

[Protesilaos Stavrou]

Yuri Khan <yuri.v.khan@gmail.com> [2020-09-15, 16:14 +0700]:

> On Tue, 15 Sep 2020 at 15:44, Protesilaos Stavrou <info@protesilaos.com> wrote:
>
>> Solarized fails on the accessibility front (not its designer's fault, as
>> that was not its goal).  Many colour combinations are well below the
>> minimum 4.5:1 threshold.  The following table shows the relative
>> luminance of all colours of the palette compared with the four base
>> background values (table's image with colour previews also attached).
>
> A color theme does not have to provide 4.5:1 contrast for each-to-each
> color combination. Only for those that are actually used to display
> text.

Correct.  We are concerned with foreground+background combinations.
Those of designated background values are to be excluded.  Basically
every entry that approximates a 1:1 contrast ratio.

>> | SOLARIZED | HEX     | #002b36 | #073642 | #eee8d5 | #fdf6e3 |
>> |-----------+---------+---------+---------+---------+---------|
>> | base03    | #002b36 |         |         |   12.25 |   13.92 |
>> | base02    | #073642 |         |         |   10.61 |   12.05 |
>> | base01    | #586e75 |         |         |    4.39 |    4.99 |
>> | base00    | #657b83 |         |         |    3.64 |    4.13 |
>> | base0     | #839496 |    4.75 |    4.11 |         |         |
>> | base1     | #93a1a1 |    5.61 |    4.86 |         |         |
>> | base2     | #eee8d5 |   12.25 |   10.61 |         |         |
>> | base3     | #fdf6e3 |   13.92 |   12.05 |         |         |
>> | yellow    | #b58900 |    4.68 |    4.05 |    2.62 |    2.98 |
>> | orange    | #cb4b16 |    3.26 |    2.82 |    3.76 |    4.27 |
>> | red       | #dc322f |    3.25 |    2.81 |    3.77 |    4.29 |
>> | magenta   | #d33682 |    3.30 |    2.86 |    3.71 |    4.21 |
>> | violet    | #6c71c4 |    3.43 |    2.97 |    3.57 |    4.06 |
>> | blue      | #268bd2 |    4.08 |    3.53 |    3.00 |    3.41 |
>> | cyan      | #2aa198 |    4.75 |    4.12 |    2.58 |    2.93 |
>> | green     | #859900 |    4.69 |    4.06 |    2.62 |    2.97 |

Thanks for clearing the table: easier to read!  Still goes to show that
several combinations are not accessible.  Those could be tweaked a bit
while retaining the overall aesthetic of the colour scheme.  Though that
is another subject altogether.  My intent is to bring the accessibility
angle into this discussion.

> Also, Solarized picked a design decision of using the same accent
> colors against dark and light backgrounds.

I did note as much in my original message.  Solarized is among the best
in what it tries to do.  Ethan Schoonover did not design for the WCAG
standard here considered, so this is not a critique against that work.
Just a suggestion that we do not need to faithfully follow the original
Solarized.

> This makes it hard to satisfy the 4.5:1 requirement, because if accent
> is at least 4.5:1 to darkest and lightest is at least 4.5:1 to accent,
> then lightest must be at least 20.25:1 to darkest, and the chosen
> Solarized lightest and darkest do not satisfy that. So, within the
> given limitations, Solarized does well enough.

I agree.  It is practically impossible to design for accessibility using
colours that are equally accessible on light and dark backgrounds, while
also remaining fairly distinct between themselves.  The background has
to be a given, so that all foreground values can be selected
accordingly.  When in doubt, assume a pure black/white backdrop and
strive for a high contrast against it, while also leveraging the ability
of 'defface' to assign attributes to a given display spec.

The 16-colour palette that has to work on both light and dark
backgrounds is a constraint that Emacs' defface can circumvent.  An
excerpt from 'M-x find-library faces':

(defface link
  '((((class color) (min-colors 88) (background light))
     :foreground "RoyalBlue3" :underline t)
    (((class color) (background light))
     :foreground "blue" :underline t)
    (((class color) (min-colors 88) (background dark))
     :foreground "cyan1" :underline t)
    (((class color) (background dark))
     :foreground "cyan" :underline t)
    (t :inherit underline))
  "Basic face for unvisited links."
  :group 'basic-faces
  :version "22.1")

If one really wants to keep it to 16 colours, then maintain two sets of
them.  One for dark, another for light.  And keep accessibility in mind.


-- 
Protesilaos Stavrou
protesilaos.com

Re: solarized

[Theodor Thornhill]

On September 15, 2020 12:16:42 PM GMT+02:00, Protesilaos Stavrou <info@protesilaos.com> wrote:

>The 16-colour palette that has to work on both light and dark
>backgrounds is a constraint that Emacs' defface can circumvent.  An
>excerpt from 'M-x find-library faces':
>
>(defface link
>  '((((class color) (min-colors 88) (background light))
>     :foreground "RoyalBlue3" :underline t)
>    (((class color) (background light))
>     :foreground "blue" :underline t)
>    (((class color) (min-colors 88) (background dark))
>     :foreground "cyan1" :underline t)
>    (((class color) (background dark))
>     :foreground "cyan" :underline t)
>    (t :inherit underline))
>  "Basic face for unvisited links."
>  :group 'basic-faces
>  :version "22.1")
>
>If one really wants to keep it to 16 colours, then maintain two sets of
>them.  One for dark, another for light.  And keep accessibility in mind.
>
>


Could it be an idea to generalize the modus themes? They seem very comprehensive

Theodor Thornhill

Re: solarized

[Gerry Agbobada]

[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]

Hello,

This is what theme generator plugins try to do : provide default faces and an API that allows users to define a theme by only specifying a set of colors and a set of overrides (if you want function-related faces to be "accent3" instead of "accent1").

Henrik tried to do it with emacs-doom-themes ( https://github.com/hlissner/emacs-doom-themes ) but apparently the theme generation part is not really good and he has been trying to find time to rewrite that part. But using that API to define a theme seems really easy : https://github.com/hlissner/emacs-doom-themes/blob/master/themes/doom-one-theme.el 

I think this is the kind of helpers that would warrant upstream integration :
- Upstream can handle changes in 
https://github.com/hlissner/emacs-doom-themes/blob/master/doom-themes-base.el default faces and the theme generation macro [1]
- theme writers or others end users just manage their color palette and the few faces they want to override

[1] : 
https://github.com/hlissner/emacs-doom-themes/blob/d6ee47dc8ed2cf9e585f62243214af03ba5b1687/doom-themes.el#L395

On Tue, Sep 15, 2020, at 15:39, Theodor Thornhill wrote:
> 
> 
> On September 15, 2020 12:16:42 PM GMT+02:00, Protesilaos Stavrou <info@protesilaos.com> wrote:
> 
> >The 16-colour palette that has to work on both light and dark
> >backgrounds is a constraint that Emacs' defface can circumvent.  An
> >excerpt from 'M-x find-library faces':
> >
> >(defface link
> >  '((((class color) (min-colors 88) (background light))
> >     :foreground "RoyalBlue3" :underline t)
> >    (((class color) (background light))
> >     :foreground "blue" :underline t)
> >    (((class color) (min-colors 88) (background dark))
> >     :foreground "cyan1" :underline t)
> >    (((class color) (background dark))
> >     :foreground "cyan" :underline t)
> >    (t :inherit underline))
> >  "Basic face for unvisited links."
> >  :group 'basic-faces
> >  :version "22.1")
> >
> >If one really wants to keep it to 16 colours, then maintain two sets of
> >them.  One for dark, another for light.  And keep accessibility in mind.
> >
> >
> 
> 
> Could it be an idea to generalize the modus themes? They seem very comprehensive
> 
> Theodor Thornhill
> 
> 

Gerry Agbobada

[-- Attachment #2: Type: text/html, Size: 3736 bytes --]

Theme generator (was: solarized)

[Stefan Monnier]

> Henrik tried to do it with emacs-doom-themes
> ( https://github.com/hlissner/emacs-doom-themes ) but apparently the theme
> generation part is not really good and he has been trying to find time to
> rewrite that part. But using that API to define a theme seems really easy :
> https://github.com/hlissner/emacs-doom-themes/blob/master/themes/doom-one-theme.el
>
> I think this is the kind of helpers that would warrant upstream integration :

Indeed, it seems that if we extended the `defface` machinery to allow
evaluation of Elisp code, we could make this "standard".


        Stefan

Re: Theme generator

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Henrik tried to do it with emacs-doom-themes
>> ( https://github.com/hlissner/emacs-doom-themes ) but apparently the theme
>> generation part is not really good and he has been trying to find time to
>> rewrite that part. But using that API to define a theme seems really easy :
>> https://github.com/hlissner/emacs-doom-themes/blob/master/themes/doom-one-theme.el
>>
>> I think this is the kind of helpers that would warrant upstream integration :
>
> Indeed, it seems that if we extended the `defface` machinery to allow
> evaluation of Elisp code, we could make this "standard".
>
>
>         Stefan

Part of  my suggestion was to turn Solarized into more general
framework. One reason beeing that it offers "conceptual framework" of
thinking about basic colors, and accented colors of which accented
colors are probably those of interest for most 3rd party package
writers. Other reason being because of author invested a great deal of
work to style existing 3rd party packages, to extent I personally have
not seen in any other theme. It makes for much more coherent experience,
then most other themes, something I would like to see with whichever
color scheme is used.

Individual colors should not be the main focus; one can use any colors
once there is a framework to easily change scemes.

I would like to see something as simple like this:



(require 'color-scheme)

(deftheme solarized-light
  "The light variant of the Solarized color theme.")

(color-scheme-create-theme 'light 'solarized-light)

(defvar solarized-base-colors nil
  "Color in use for monobase colors.")

(defvar solarized-accented-colors nil
  "Current color in use for accented colors.")


(setq solarized-base-colors ["#002b36"
                             "#073642"
                             "#586e75"
                             "#657b83"
                             "#839496"
                             "#93a1a1"
                             "#eee8d5"
                             "#fdf6e3"])

(setq solarized-accented-colors ["#b58900" ;yellow
                                 "#cb4b16" ;orange
                                 "#dc322f" ;red
                                 "#d33682" ;magenta
                                 "#6c71c4" ;violet
                                 "#268bd2" ;blue
                                 "#2aa198" ;cyan
                                 "#859900" ;green
                                 ])

(color-scheme-set-colors
     solarized-base-colors
     solarized-accented-colors)

(provide-theme 'solarized-light)

Yes, that is what theme-generators do. What I would like to see extra in
Emacs is a manual entry docs on how to use color scheme in theme
creation as well as in 3rd party pacakges that output data into gui
elements, so that themes don't have to individually look in
3rd party code and set faces afterword to make them visually consistent
with rest of Emacs world (as done in Bozhidar's Solarized or base16 and
other themes and generators).

Re: Theme generator

[Stefan Monnier]

>> Indeed, it seems that if we extended the `defface` machinery to allow
>> evaluation of Elisp code, we could make this "standard".
> Part of  my suggestion was to turn Solarized into more general
> framework.

Indeed my remark aims at another part: to define such a framework you
need some way for each face to "compute itself" based on some
settings elsewhere.  Extending the `defface` machinery would make such
"compute itself" possible without extra gymnastics.  It would in itself
introduce a framework, but might make such a framework better fit into
the rest of the system, I think.


        Stefan

Re: Theme generator

[Stefan Monnier]

> Indeed my remark aims at another part: to define such a framework you
> need some way for each face to "compute itself" based on some
> settings elsewhere.  Extending the `defface` machinery would make such
> "compute itself" possible without extra gymnastics.  It would in itself
                                                               ^
                                                              n't

> introduce a framework, but might make such a framework better fit into
> the rest of the system, I think.


        Stefan

Re: Theme generator

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Indeed my remark aims at another part: to define such a framework you
>> need some way for each face to "compute itself" based on some
>> settings elsewhere.  Extending the `defface` machinery would make such
>> "compute itself" possible without extra gymnastics.  It would in itself
>                                                                ^
>                                                               n't
>
>> introduce a framework, but might make such a framework better fit into
>> the rest of the system, I think.
>
>
>         Stefan

You are definitely correct; I am not that knowledgable about "defface
machinery" and how it works under the hood, so it is behind my skills;
but, conceptucally, I understand correct, it would eliminate need for
theme creators to skin at least Emacs built-in gui elements if defface
could pick values automatically from some "skinning" framework.

Re: Theme generator (was: solarized)

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]

I think this is a better approach than trying to come up with a definitive
set of themes. The 'look' of your editor is a pretty personal preference
and we are unlikely to find a definitive set of themes that will suit all.
On the other hand, if we can make it easier to define a theme, we are
enabling people to make it look the way they want, which seems to be part
of the core essence of Emacs - do it your way.

At present, while you have all the power to customize faces, it isn't
necessary easy to get things consistent. Defining a new theme usually takes
a lot of trial and error. It has certainly improved since I first started
with Emacs in the 90s, but could probably be improved further with a theme
generator. The big challenge is that Emacs has far more 'faces' than other
editors and it sin't always clear how all these faces interact. Some sort
of theme generator which could help with this would make it easier for
people to define their own themes.

The spacemacs setup also has a pretty straight-forward way to tweak
existing themes with their theming-modifications list, which makes it easy
to tweak specific settings for specific themes (and ensures they are
applied when themes change or are re-loaded etc).



On Wed, 16 Sep 2020 at 00:43, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > Henrik tried to do it with emacs-doom-themes
> > ( https://github.com/hlissner/emacs-doom-themes ) but apparently the
> theme
> > generation part is not really good and he has been trying to find time to
> > rewrite that part. But using that API to define a theme seems really
> easy :
> >
> https://github.com/hlissner/emacs-doom-themes/blob/master/themes/doom-one-theme.el
> >
> > I think this is the kind of helpers that would warrant upstream
> integration :
>
> Indeed, it seems that if we extended the `defface` machinery to allow
> evaluation of Elisp code, we could make this "standard".
>
>
>         Stefan
>
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2832 bytes --]

Re: Theme generator (was: solarized)

[chad]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

On Tue, Sep 15, 2020 at 6:49 PM Tim Cross <theophilusx@gmail.com> wrote:

>
> At present, while you have all the power to customize faces, it isn't
> necessary easy to get things consistent. [...]
>
> The spacemacs setup also has a pretty straight-forward way to tweak
> existing themes with their theming-modifications list, which makes it easy
> to tweak specific settings for specific themes (and ensures they are
> applied when themes change or are re-loaded etc).
>

I recently tried to do a very similar task in a way that didn't feel hacky.
I set myself a pretty short timeout, and didn't make it, so this idea
sounds interesting. Digging in, I found this example (link to github):
https://github.com/syl20bnr/spacemacs/tree/develop/layers/%2Bthemes/theming#example

(defun dotspacemacs/user-init ()
  (setq theming-modifications
        '((monokai
           ;; Font locking
           (font-lock-comment-face :slant italic)
           (web-mode-html-attr-name-face :inherit font-lock-variable-name-face
                                         :foreground nil)
           ;; Modeline
           (powerline-active1 :box (:color "#999999"
                                    :line-width 1
                                    :style released-button)
                              :background "#5a5a5a")))))


That seems useful (although not enough, personally, to drag in all of
spacemacs). Has anyone else tried this "theme layer" from Spacemacs? Should
we try to adapt it to emacs core?

Thanks!
~Chad

[-- Attachment #2: Type: text/html, Size: 3562 bytes --]

Re: Theme generator

[Arthur Miller]

chad <yandros@gmail.com> writes:

> On Tue, Sep 15, 2020 at 6:49 PM Tim Cross <theophilusx@gmail.com> wrote:
>
>  At present, while you have all the power to customize faces, it isn't necessary easy to get things consistent. [...]
>
>  The spacemacs setup also has a pretty straight-forward way to tweak existing themes with their theming-modifications list,
>  which makes it easy to tweak specific settings for specific themes (and ensures they are applied when themes change or are
>  re-loaded etc).
>
> I recently tried to do a very similar task in a way that didn't feel hacky. I set myself a pretty short timeout, and didn't make it, so
> this idea sounds interesting. Digging in, I found this example (link to github):
> https://github.com/syl20bnr/spacemacs/tree/develop/layers/%2Bthemes/theming#example
>
> (defun dotspacemacs/user-init ()
>   (setq theming-modifications
>         '((monokai
>            ;; Font locking
>            (font-lock-comment-face :slant italic)
>            (web-mode-html-attr-name-face :inherit font-lock-variable-name-face
>                                          :foreground nil)
>            ;; Modeline
>            (powerline-active1 :box (:color "#999999"
>                                     :line-width 1
>                                     :style released-button)
>                               :background "#5a5a5a")))))
>

Here is visible what is a problem with current theme engine: 

>            (powerline-active1 :box (:color "#999999"
>                                     :line-width 1
>                                     :style released-button)
>                               :background "#5a5a5a")))))


In order to syle an element 3rd party package will specify raw rgb
values for an element. If theme-engine offered parametrized names like
say, :color color-scheme-foreground instead of #999999, then when user
sets a color for the color-scheme-foreground the element would pick it
up from the theme and there would be no need for 4th party developer,
theme modders, like base16 or Solarized devs, to look at the code, and
re-style it in their own code to bring that package into their theme.
See for example:

;;;; powerline
     `(powerline-active1 ((,class ,(if solarized-high-contrast-mode-line
                                       `(:background ,base00 :foreground ,base03)
                                     `(:background ,base03 :foreground ,base00)))))
     `(powerline-active2 ((,class ,(if solarized-high-contrast-mode-line
                                       `(:background ,base01 :foreground ,base03)
                                     `(:background ,base02 :foreground ,base00)))))
     `(powerline-inactive1 ((,class ,(if solarized-high-contrast-mode-line
                                         `(:background ,base03 :foreground ,base1)
                                       `(:background ,base02 :foreground ,base01)))))
     `(powerline-inactive2 ((,class ,(if solarized-high-contrast-mode-line
                                         `(:background ,base02 :foreground ,base1)
                                       `(:background ,base03 :foreground
     ,base01)))))

as found in Solarized:

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

Thomas "linuxteam" suggested to use faces instead of colors, which
probably is even better then using just colors, albeit it might be that
color framework is needed at lower level to customize faces. I am not
really sure, since I am not so acquainted with face-machinery and how it
really works (yet).

Re: Theme generator (was: solarized)

[Richard Stallman]

[[[ 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. ]]]

  > Indeed, it seems that if we extended the `defface` machinery to allow
  > evaluation of Elisp code, we could make this "standard".

Would you like to make a concrete proposal so we can think about it?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: solarized

[Protesilaos Stavrou]

Theodor Thornhill <theo@thornhill.no> [2020-09-15, 15:39 +0200]:

> Could it be an idea to generalize the modus themes? They seem very
> comprehensive

I don't think I have the expertise to implement a generic theme
framework.  If there are concrete proposals on offer, I can help by
sending feedback.

-- 
Protesilaos Stavrou
protesilaos.com

Re: solarized

[Praharsh Suryadevara]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

There is a generic theme framework called base 16 here which includes good
looking themes including solarized (or a version of it)
http://chriskempson.com/projects/base16/#:~:text=An%20architecture%20for%20building%20themes,compiling%20base16%20schemes%20and%20templates.


Thanks,
Praharsh





On Tue, Sep 15, 2020 at 3:28 PM Protesilaos Stavrou <info@protesilaos.com>
wrote:

> Theodor Thornhill <theo@thornhill.no> [2020-09-15, 15:39 +0200]:
>
> > Could it be an idea to generalize the modus themes? They seem very
> > comprehensive
>
> I don't think I have the expertise to implement a generic theme
> framework.  If there are concrete proposals on offer, I can help by
> sending feedback.
>
> --
> Protesilaos Stavrou
> protesilaos.com
>
>

[-- Attachment #2: Type: text/html, Size: 1479 bytes --]

Re: solarized

[Richard Stallman]

[[[ 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. ]]]

  > I agree.  It is practically impossible to design for accessibility using
  > colours that are equally accessible on light and dark backgrounds, while
  > also remaining fairly distinct between themselves.  The background has
  > to be a given, so that all foreground values can be selected
  > accordingly.

I think you are right.  But this suggests an idea to me.  Would it
make sense to design a color palette, in the same systematic way as
Solarized, but with only dark backgrounds, and the other colors meant
to contrast with those?

And then invert it for light backgrounds?


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: solarized

[Protesilaos Stavrou]

Richard Stallman <rms@gnu.org> [2020-09-16, 01:05 -0400]:

>   > I agree.  It is practically impossible to design for accessibility using
>   > colours that are equally accessible on light and dark backgrounds, while
>   > also remaining fairly distinct between themselves.  The background has
>   > to be a given, so that all foreground values can be selected
>   > accordingly.
>
> I think you are right.  But this suggests an idea to me.  Would it
> make sense to design a color palette, in the same systematic way as
> Solarized, but with only dark backgrounds, and the other colors meant
> to contrast with those?
>
> And then invert it for light backgrounds?

So you mean to develop two distinct sets of colours?  One set consists
of dark backgrounds and appropriate variants of red, green, blue,
etc. that are meant to work well with those backgrounds.  Then another
set for the light version, again with bespoke variants of red, green,
blue, etc.

I think that is desirable if you plan to develop for a minimum WCAG
accessibility target of 4.5:1 colour contrast (as noted in my previous
message) without facing any artificial constraint.

If someone comes up with an implementation of such a new theme framework
that is sufficiently different from the current themes, I am prepared to
send feedback with regard to the choice of colour values.

* * *

On another note, do we really need to strictly conform with the
16-colour palette?  I understand this is the standard for terminal
emulators (maybe not all of them), but Emacs has more options than that.
Perhaps define an "extended palette" for GUIs and let the 16-colour
"base palette" for TTYs.

In my experience, 16 colours is too limited of a set to design bespoke,
usable, and pleasing interfaces that match the wide array of needs an
Emacs user has.  For example, you need a set of slightly accented
backgrounds that are not the same as the standard accented foregrounds
(red/green/blue/etc), such as to display diff buffers.  Inverting the
main background with the standard accented foreground "just works"
though it leads to too intense, too crude of a result, i.e. it is
sub-optimal due to an unnecessary compromise.  Then you need another
shade of such accented backgrounds to also paint refined (word-wise)
changes in diffs.  For Magit, if you use that, you may need a third
variant for the focused diff hunk…

Extend this to isearch's current and lazy matches, occur's matches which
should not be the same as isearch's to avoid conflicts (because you can
search in an occur buffer), the regexp groups of re-builder, the
numerous components of completion frameworks like Ivy/Helm, and so on.

To me colours are akin to a tool kit: use the right set for the job.
Keep the 16 colour "base palette" for terminal emulators and let GUI
have as many as would be deemed necessary in the "extended palette".

Even the Solarized theme for Emacs defines far more colours[0] than the
original 16 in Ethan Schoonover's work.[1] It thus is not a faithful
implementation of Solarized, strictly speaking (though I obviously am
okay with that).

[0]: https://github.com/bbatsov/solarized-emacs/blob/master/solarized-palettes.el
[1]: https://ethanschoonover.com/solarized/

-- 
Protesilaos Stavrou
protesilaos.com

Re: solarized

[Arthur Miller]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

Protesilaos Stavrou <info@protesilaos.com> writes:


> On another note, do we really need to strictly conform with the
> 16-colour palette?
Batsov's Solarized gives you total of 32 colors. I certainly don't want to see
all 32 colors at once in the gui :-). Anyway 16 of those are ment for
extreme cases, and are just shades of eight accented colors, ligher and darker.

If those are not enough for some extreme case, user can always do what
they do now, specify rgb value directly; but for *most* part, hopefully
16 colors would be enough. Nobody said it has to be enough for
*everybody everywhere*.

> In my experience, 16 colours is too limited of a set to design bespoke,
> usable, and pleasing interfaces that match the wide array of needs an
> Emacs user has.
Design literature on contrary says something in lines of "less is more",
both when it comes to color and form.

Too many colors and you get rainbow. Look at dired+ screenshot I
attached. Every "property" is coded in different color, and it just
looks horrible when put together.

Another subject, similar to gui theme colors, is syntax highlighting. Too much
syntax highlighting can be as detrimental as none, see for example this paper:

https://pdfs.semanticscholar.org/d14b/edf3f58080ecf7a92f60746371b894a7bc08.pdf

and this screenshot:

https://imgur.com/zhCs4Bv

Maybe some thoughts here:

https://www.linusakesson.net/programming/syntaxhighlighting/


[-- Attachment #2: Screenshot of dired --]
[-- Type: image/png, Size: 50307 bytes --]

Re: solarized

[Richard Stallman]

[[[ 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. ]]]

  > > And then invert it for light backgrounds?

  > So you mean to develop two distinct sets of colours? 

No, just one set.  Then compute the inverse of the colors
in that set.

By inverse I mean, the color that is to white as color X is to black.
I don't know what formula is needed for that, but I presume someone does.

  > On another note, do we really need to strictly conform with the
  > 16-colour palette?

I am not sure what "need to" means.  It has been pointed out, though,
that too many colors results in confusion.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: solarized

[Gian Uberto Lauri]

>>>>> "RS" == Richard Stallman <rms@gnu.org> writes:

RS> No, just one set.  Then compute the inverse of the colors in that
RS> set.

RS> By inverse I mean, the color that is to white as color X is to
RS> black.  I don't know what formula is needed for that, but I
RS> presume someone does.

I think it is something that could be described as

	the value of each member of the inverse triplet is #FF minus
	the value of the corresponding member in the original triplet,
	that is "computes the complementary color"

but I fear that other things impact on the perception of the colors,
i.e. the monitor settings, cultural background (don't be surprised, it
is human perception after all, and it's strongly influenced by
psycological components including the name you give to colors, see the
Himbas in Africa, and Japan - I think that they see shades of grue
[see
https://www.japantimes.co.jp/life/2013/02/25/language/the-japanese-traffic-light-blues-stop-on-red-go-on-what/]).

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

RE: solarized

[Drew Adams]

> RS> By inverse I mean, the color that is to white as color X is to
> RS> black.  I don't know what formula is needed for that, but I
> RS> presume someone does.
> 
> I think it is something that could be described as
> 
> 	the value of each member of the inverse triplet is #FF minus
> 	the value of the corresponding member in the original triplet,
> 	that is "computes the complementary color"
> 
> but I fear that other things impact on the perception of the colors,
> i.e. the monitor settings, cultural background (don't be surprised, it
> is human perception after all, and it's strongly influenced by
> psycological components including the name you give to colors, see the
> Himbas in Africa, and Japan - I think that they see shades of grue

There is the human-perception consideration.
And as others have pointed out, that is heavily
influenced by things such as ambient lighting.

As for color complementing, without taking such
perception considerations into account, there
is already existing Emacs code for getting the
complement (inverse, if you prefer) of a color.

There are functions to complement each of hue,
saturation, and value.  There are functions to
complement all (the combination) together, for
color name, RGB numeric, or RGB hex values.

Standard library color.el has only the latter
(fixed combination formula, based on RGB/name).
Library hexrgb.el has all of them.

https://www.emacswiki.org/emacs/download/hexrgb.el

Re: solarized

[Richard Stallman]

[[[ 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. ]]]

  > 	the value of each member of the inverse triplet is #FF minus
  > 	the value of the corresponding member in the original triplet,
  > 	that is "computes the complementary color"

  > but I fear that other things impact on the perception of the colors,

I agree.  That is why I don't know what formula to propose for
inverting a color.  But we can find that out a reasonable one.

  > i.e. the monitor settings, cultural background

To recommend or specify a set of color values
is to presume that it is possible to get useful results
without worrying about those sources of variation.
(And personal taste, too.)

Emacs does specify a default set of color values, and it must do so.
Thus, Emacs must make that presumption.  So it is ok to try
another solution which also depends on that presumption.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: solarized

[Richard Stallman]

[[[ 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. ]]]

Here is an idea for dealing with monitor variations, cultural variations
in color perception, and personal quirks.

We could have a color-tuning feature that lets a user adjust slowly,
in any direction, each color in the color palette that Emacs faces
use.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: solarized

[Drew Adams]

> Here is an idea for dealing with monitor variations, cultural variations
> in color perception, and personal quirks.
> 
> We could have a color-tuning feature that lets a user adjust slowly,
> in any direction, each color in the color palette that Emacs faces
> use.

This is something I mentioned in the context of
the discussion about theme adjustment/generation.

Library `Do Re Mi' lets you do exactly that, with
an individual face or all faces: incrementally
(as fine or gross an increment as you like) change
hue, saturation, value, red, green, or blue, and
even combinations.

For example, command `doremi-face-fg+' lets you
change foreground and background colors of a
face by incrementing/decrementing its RGB or
HSV components.  A popup frame shows you sample
text in the face as it changes, as well as
sample text in the previous value of the face.

You can do this quickly (or slowly), with cycle
keys (e.g. arrows) or with a mouse wheel.

https://www.emacswiki.org/emacs/DoReMi#doremi-frm.el

Re: solarized

[Arthur Miller]

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. ]]]
>
>   > > And then invert it for light backgrounds?
>
>   > So you mean to develop two distinct sets of colours? 
>
> No, just one set.  Then compute the inverse of the colors
> in that set.
>
> By inverse I mean, the color that is to white as color X is to black.
> I don't know what formula is needed for that, but I presume someone does.
Yes, it would be possible; by choosing some criteria for difference in
contrast or shade or some other, for example by choosing a complementary
colors could be one way, or tertiary colors or some other "predefined
way". But people might not be satisfied with the choice for any reason,
so maybe some functionality to precompute a shade from a given shade and
desired contrast, could be added as well.

Re: solarized

[Tim Cross]

Arthur Miller <arthur.miller@live.com> writes:

> 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. ]]]
>>
>>   > > And then invert it for light backgrounds?
>>
>>   > So you mean to develop two distinct sets of colours? 
>>
>> No, just one set.  Then compute the inverse of the colors
>> in that set.
>>
>> By inverse I mean, the color that is to white as color X is to black.
>> I don't know what formula is needed for that, but I presume someone does.
> Yes, it would be possible; by choosing some criteria for difference in
> contrast or shade or some other, for example by choosing a complementary
> colors could be one way, or tertiary colors or some other "predefined
> way". But people might not be satisfied with the choice for any reason,
> so maybe some functionality to precompute a shade from a given shade and
> desired contrast, could be added as well.

While I think these discussions are very valuable, I just wanted to
mention one aspect of the Solarized theme which I think is quite
important. It is one of the few themes with a defined underlying
philosophy/principal. Many other themes are just something someone has
defined, felt it looked good and released it. Solarized has a more
formal definition.

This is important because it makes the theme fairly consistent across
different applications. You can add this theme to your terminal, your
window manager, your browser, various editors etc and get a consistent
scheme across the board.

Consider the situation now with M-x customize-theme. There is a list of
themes and some of them are likely known (such as 'tango') while others
are probably unknown and you can only try them out to see what they look
like. The ones which are known are likely very similar to themes of the
same name used in other applications, but perhaps not quite because they
lack a clear definition/philosophy.

Adding solarized-light and solarized-dark to that list of available
themes would provide a theme which may be more consistent to other
applications using that theme. This could help new users in getting an
initial look which is familiar and provide a comfortable starting point
with very little effort. As reducing the cognitive difference level for
new users is likely beneficial, adding this theme would seem to have
some benefits with very little downside.

We can probably define a theme which is better than Solarized, but that
is a different objective IMO. What we should avoid doing is implementing
a theme called Solarized which is 'improved' or different from the
original definition - call it something else.

-- 
Tim Cross

Re: solarized

[Richard Stallman]

[[[ 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. ]]]

  > While I think these discussions are very valuable, I just wanted to
  > mention one aspect of the Solarized theme which I think is quite
  > important. It is one of the few themes with a defined underlying
  > philosophy/principal. Many other themes are just something someone has
  > defined, felt it looked good and released it. Solarized has a more
  > formal definition.

I understand that.  I'm proposing to do something similar except
eliminating the goal of light-dark inversion symmetry.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: solarized

[Tim Cross]

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. ]]]
>
>   > While I think these discussions are very valuable, I just wanted to
>   > mention one aspect of the Solarized theme which I think is quite
>   > important. It is one of the few themes with a defined underlying
>   > philosophy/principal. Many other themes are just something someone has
>   > defined, felt it looked good and released it. Solarized has a more
>   > formal definition.
>
> I understand that.  I'm proposing to do something similar except
> eliminating the goal of light-dark inversion symmetry.

Which is great and perhaps this will result in an even better theme. In
the meantime, adding Solarized as another choice from the list of
already available themes would be an easy enhancement and provide a
theme which is popular and familiar, which could ease transition for some new users.

-- 
Tim Cross

Re: solarized

[Arthur Miller]

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. ]]]
>
>   > While I think these discussions are very valuable, I just wanted to
>   > mention one aspect of the Solarized theme which I think is quite
>   > important. It is one of the few themes with a defined underlying
>   > philosophy/principal. Many other themes are just something someone has
>   > defined, felt it looked good and released it. Solarized has a more
>   > formal definition.
>
> I understand that.  I'm proposing to do something similar except
> eliminating the goal of light-dark inversion symmetry.

Regardless of the colors choice; what I find useful is the logical
separation of color in two sorts: base colors and accent colors. Accents
are ment to be used for things that has to stand out, like a window
number on modeline, or a reserved word in a programming language. Base
colors are those used as bg/fg and other basic things that many packages
in Emacs don't need to touch. For that reason I think Solarized approach
is good for a framework choice.

If 8+8 is enough or not, I don't know. Maybe Batsov's approach is good
about a variation of accents colors, 8 lighter + 8 darker which can be
calculated by elisp automatically, or maybe some other division is better?

For the color choice, it is personal preference; I am sure different
cultures can manage color choices for themselves; i.e; make the
framework provide mechanism not policy.

For the concrete proposal, maybe it is best to start by providing a
framework of logical placeholders as well worded by Dmitry (I think) as
a first step; once there is a framework let then speak about some color
functions and elisp to automate calculation of choice, inversions etc.

Re: solarized

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:
                                                        Would it
> make sense to design a color palette, in the same systematic way as
> Solarized, but with only dark backgrounds, and the other colors meant
> to contrast with those?
> And then invert it for light backgrounds?
Of course it could. Solarized design made particular choices in order to
have same accent color in both dark and light versions. So if say C++
syntax used those colors, say pink for reserved words, they would be same
color in both light and dark version and retain same amount of contrast.

But that choice does not need to be a design demand for Emacs. Also
every theme does not need to have dark and light versions either, but it
is cool if there is a framework to create such themes with ease.

The framework I would like to see, either based on Solarized or base16
themes, could be made so that theme specify a palette of colors,
and then the software calculates "right" shades based on some contrast
values, intensity difference, whatever.

I have seen in color.el and shr-color.el some code to do something
similar (they could be merged both in one file: color.el). One could
also have "high-contrast" and "low-contrast" themes calculated
automaticly. Maybe :-).

Re: solarized

[Richard Stallman]

[[[ 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. ]]]

  > Of course it could. Solarized design made particular choices in order to
  > have same accent color in both dark and light versions.

What I read about Solarized described some other goals that sounded
interesting.  Perhaps using those other goals _without_ the goal of
bidirectionality would give interesting results.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: solarized

[Göktuğ Kayaalp]

On 2020-09-15 11:29 +03, Protesilaos Stavrou <info@protesilaos.com> wrote:
> My opinion is that Emacs' default faces should be designed with
> accessibility (readability) in mind.  A minimum contrast ratio of 4.5:1
> between a given foreground and background combination ensures that Emacs
> will be readable out-of-the-box for the majority of people.  If you want
> to be even more inclusive, a minimum 7:1 contrast ratio is recommended.

+1000000000.

It’s not generally considered in terms of a11y but as someone with a
generous amount of astigmatism I can say that Solarized is almost as
blinding as looking into the sun itself for me.

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: solarized

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Tue, 15 Sep 2020, 19:27 Göktuğ Kayaalp, <self@gkayaalp.com> wrote:

>
> It’s not generally considered in terms of a11y but as someone with a
> generous amount of astigmatism I can say that Solarized is almost as
> blinding as looking into the sun itself for me.
>

Interesting. For me, who has enough astigmatism to make it completely
impossible to read anything with dark backgrounds, I find solarised to have
way too little contrast. The yellow background is much too dark for me.

>

[-- Attachment #2: Type: text/html, Size: 985 bytes --]

Re: solarized

[Göktuğ Kayaalp]

On 2020-09-15 15:15 +03, Elias Mårtenson <lokedhs@gmail.com> wrote:
> Interesting. For me, who has enough astigmatism to make it completely
> impossible to read anything with dark backgrounds, I find solarised to have
> way too little contrast. The yellow background is much too dark for me.

I too prefer light backgrounds (just switched to modus-operandi and it’s
_great_ btw). Both dark and light Solarized have the ‘art exhibition’
effect for me: trying to read the writing on exhibition / museum walls,
which is almost always thin type in dim white letters over grayish walls
with almost no contrast, I always get headaches 10 minutes in.


--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: solarized

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

On Tue, 15 Sep 2020 at 23:07, Göktuğ Kayaalp <self@gkayaalp.com> wrote:

> On 2020-09-15 15:15 +03, Elias Mårtenson <lokedhs@gmail.com> wrote:
> > Interesting. For me, who has enough astigmatism to make it completely
> > impossible to read anything with dark backgrounds, I find solarised to
> have
> > way too little contrast. The yellow background is much too dark for me.
>
> I too prefer light backgrounds (just switched to modus-operandi and it’s
> _great_ btw). Both dark and light Solarized have the ‘art exhibition’
> effect for me: trying to read the writing on exhibition / museum walls,
> which is almost always thin type in dim white letters over grayish walls
> with almost no contrast, I always get headaches 10 minutes in.
>
>
> --
> İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
> pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427
>
> This is the challenge WRT accessibility. For me, with very poor vision
(legally blind), I find Solarized dark theme to be one of the most
accessible themes I've used. I have a real problem with 'light' themes and
need themes with a darker background. Unfortunately, I also have problems
with some 'pink' or 'purple' colours, which just appear blurred to me.

The solarised themse are good themes and quite popular and I think they
should definitely be added to the default set of themes included in Emacs.
Whether either of them should be the default theme is another question, but
it would be good to be able to just turn them on if needed.



-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2314 bytes --]

Re: solarized

[Göktuğ Kayaalp]

On 2020-09-16 04:30 +03, Tim Cross <theophilusx@gmail.com> wrote:
> This is the challenge WRT accessibility. For me, with very poor vision
> (legally blind), I find Solarized dark theme to be one of the most
> accessible themes I've used. I have a real problem with 'light' themes and
> need themes with a darker background. Unfortunately, I also have problems
> with some 'pink' or 'purple' colours, which just appear blurred to me.

FWIW I’d say Solarized Dark is far tamer than the light version, and it
sometimes feels like the light version was never intended seriously by
the colourscheme’s original creator.

> The solarised themse are good themes and quite popular and I think they
> should definitely be added to the default set of themes included in Emacs.
> Whether either of them should be the default theme is another question, but
> it would be good to be able to just turn them on if needed.

That’s why I think fiddling with defaults is kinda missing the point.
We all have what our minds want and bodies need, and the colours of a
program we’ll use a lot, if configurable, is one of the first things
we’ll adjust.  When I watch coding videos for example, I rarely see
people sticking to even VS Code’s or Sublime Text’s default
colourschemes, which are dark and ‘trendy’.  So it might not be worth
the breakage.

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: solarized

[Arthur Miller]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> On 2020-09-16 04:30 +03, Tim Cross <theophilusx@gmail.com> wrote:
>> This is the challenge WRT accessibility. For me, with very poor vision
>> (legally blind), I find Solarized dark theme to be one of the most
>> accessible themes I've used. I have a real problem with 'light' themes and
>> need themes with a darker background. Unfortunately, I also have problems
>> with some 'pink' or 'purple' colours, which just appear blurred to me.
>
> FWIW I’d say Solarized Dark is far tamer than the light version, and it
> sometimes feels like the light version was never intended seriously by
> the colourscheme’s original creator.
Observer word "feel" you are using. "Feel" refers to a subjective
perception. As I understand original author's page, original colors were
"calculated" not intended to work with each other. The goal was to offer
same contrast when using both light and dark colors. Whether that amount
of contrast is enough, good, likeable etc is probably anyone's personal
preferance.

>> The solarised themse are good themes and quite popular and I think they
>> should definitely be added to the default set of themes included in Emacs.
>> Whether either of them should be the default theme is another question, but
>> it would be good to be able to just turn them on if needed.
>
> That’s why I think fiddling with defaults is kinda missing the point.
> We all have what our minds want and bodies need, and the colours of a
> program we’ll use a lot, if configurable, is one of the first things
> we’ll adjust.  When I watch coding videos for example, I rarely see
> people sticking to even VS Code’s or Sublime Text’s default
> colourschemes, which are dark and ‘trendy’.  So it might not be worth
> the breakage.
For that reason Solarized, among other themes can be included and left
for people to switch if they prefer.

Re: solarized

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

On Wed, 16 Sep 2020 at 20:21, Göktuğ Kayaalp <self@gkayaalp.com> wrote:

> On 2020-09-16 04:30 +03, Tim Cross <theophilusx@gmail.com> wrote:
>
> > The solarised themse are good themes and quite popular and I think they
> > should definitely be added to the default set of themes included in
> Emacs.
> > Whether either of them should be the default theme is another question,
> but
> > it would be good to be able to just turn them on if needed.
>
> That’s why I think fiddling with defaults is kinda missing the point.
> We all have what our minds want and bodies need, and the colours of a
> program we’ll use a lot, if configurable, is one of the first things
> we’ll adjust.  When I watch coding videos for example, I rarely see
> people sticking to even VS Code’s or Sublime Text’s default
> colourschemes, which are dark and ‘trendy’.  So it might not be worth
> the breakage.
>
>
What I meant was having solarised as one of the options in the themes
included by default as opposed to making it the default theme. I am one of
those who almost always will need to tweak any theme because of specific
vision issues I have. Starting with a good base theme and tweaking from
there is a lot easier than having to start with a theme which is less
suitable.  Emacs current comes with 14 'default' themes - I was just
suggesting adding a version of solarized-light and solarised-dark to that
list.

In the long-term, I think an API and theme generator which makes it easier
to create consistent or customize existing themes is the real solution.
Emacs already has the most flexible infrastructure for creating themes, but
working at the low level. setting each face individually, is slow and
difficult, requiring lots of trial and error to get right. A good theme
generator could make this easier, continuing Emacs' customizable and
extensible forte.

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2542 bytes --]

Re: solarized

[Arthur Miller]

Tim Cross <theophilusx@gmail.com> writes:

> On Wed, 16 Sep 2020 at 20:21, Göktuğ Kayaalp <self@gkayaalp.com> wrote:
>
>  On 2020-09-16 04:30 +03, Tim Cross <theophilusx@gmail.com> wrote:
>
>  > The solarised themse are good themes and quite popular and I think they
>  > should definitely be added to the default set of themes included in Emacs.
>  > Whether either of them should be the default theme is another question, but
>  > it would be good to be able to just turn them on if needed.
>
>  That’s why I think fiddling with defaults is kinda missing the point.
>  We all have what our minds want and bodies need, and the colours of a
>  program we’ll use a lot, if configurable, is one of the first things
>  we’ll adjust.  When I watch coding videos for example, I rarely see
>  people sticking to even VS Code’s or Sublime Text’s default
>  colourschemes, which are dark and ‘trendy’.  So it might not be worth
>  the breakage.
>
> What I meant was having solarised as one of the options in the themes included by default as opposed to making it the default
> theme.
My opinion too when I suggested it.

> In the long-term, I think an API and theme generator which makes it easier to create consistent or customize existing themes is the
> real solution. Emacs already has the most flexible infrastructure for creating themes, but working at the low level. setting each
> face individually, is slow and difficult, requiring lots of trial and error to get right. A good theme generator could make this easier,
> continuing Emacs' customizable and extensible forte. 
Exactly.

Re: solarized

[Stefan Kangas]

Tim Cross <theophilusx@gmail.com> writes:

> What I meant was having solarised as one of the options in the themes
> included by default as opposed to making it the default theme. I am one of
> those who almost always will need to tweak any theme because of specific
> vision issues I have. Starting with a good base theme and tweaking from
> there is a lot easier than having to start with a theme which is less
> suitable.  Emacs current comes with 14 'default' themes - I was just
> suggesting adding a version of solarized-light and solarised-dark to that
> list.

I don't imagine that anyone would be against that.  Why would they?

But we would need the help of the theme author to ensure that copyright
assignments are in order before it could be included in vanilla.  Maybe
someone interested in that could help look into it.

> In the long-term, I think an API and theme generator which makes it easier
> to create consistent or customize existing themes is the real solution.
> Emacs already has the most flexible infrastructure for creating themes, but
> working at the low level. setting each face individually, is slow and
> difficult, requiring lots of trial and error to get right. A good theme
> generator could make this easier, continuing Emacs' customizable and
> extensible forte.

I agree, FWIW.  It would be useful if someone could propose a patch or
start working on it in a feature branch, I think.

Re: solarized

[Arthur Miller]

Stefan Kangas <stefankangas@gmail.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> What I meant was having solarised as one of the options in the themes
>> included by default as opposed to making it the default theme. I am one of
>> those who almost always will need to tweak any theme because of specific
>> vision issues I have. Starting with a good base theme and tweaking from
>> there is a lot easier than having to start with a theme which is less
>> suitable.  Emacs current comes with 14 'default' themes - I was just
>> suggesting adding a version of solarized-light and solarised-dark to that
>> list.
>
> I don't imagine that anyone would be against that.  Why would they?
>
> But we would need the help of the theme author to ensure that copyright
> assignments are in order before it could be included in vanilla.  Maybe
> someone interested in that could help look into it.
>
>> In the long-term, I think an API and theme generator which makes it easier
>> to create consistent or customize existing themes is the real solution.
>> Emacs already has the most flexible infrastructure for creating themes, but
>> working at the low level. setting each face individually, is slow and
>> difficult, requiring lots of trial and error to get right. A good theme
>> generator could make this easier, continuing Emacs' customizable and
>> extensible forte.
>
> I agree, FWIW.  It would be useful if someone could propose a patch or
> start working on it in a feature branch, I think.
You mean Batsov's? He is author of the Emacs Prelude, a starter kit, so
I guess he will not mind. If he is not lurking on this list himeself I
can send him a mail and ask.

Re: solarized

[Arthur Miller]

Stefan Kangas <stefankangas@gmail.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> What I meant was having solarised as one of the options in the themes
>> included by default as opposed to making it the default theme. I am one of
>> those who almost always will need to tweak any theme because of specific
>> vision issues I have. Starting with a good base theme and tweaking from
>> there is a lot easier than having to start with a theme which is less
>> suitable.  Emacs current comes with 14 'default' themes - I was just
>> suggesting adding a version of solarized-light and solarised-dark to that
>> list.
>
> I don't imagine that anyone would be against that.  Why would they?
>
> But we would need the help of the theme author to ensure that copyright
> assignments are in order before it could be included in vanilla.  Maybe
> someone interested in that could help look into it.
Mail send to him.
>> In the long-term, I think an API and theme generator which makes it easier
>> to create consistent or customize existing themes is the real solution.
>> Emacs already has the most flexible infrastructure for creating themes, but
>> working at the low level. setting each face individually, is slow and
>> difficult, requiring lots of trial and error to get right. A good theme
>> generator could make this easier, continuing Emacs' customizable and
>> extensible forte.
>
> I agree, FWIW.  It would be useful if someone could propose a patch or
> start working on it in a feature branch, I think.
I proposed a concrete suggestion in some earlier email:

* parametrize names used in the theme: base and accented;
* remove some of color blending/variant stuff that is specific for
  Solarized only
* create an api with good logical placeholder names in something like
  color-scheme.el or similar to be included by both cus-theme.el and by
  the end user
* create appropriate custom interface to it
* write nice doc/tips/guide for theme developers as well as for end
  users on how to use colors for basic elements vs accents

If such division in framework as "base" vs accentuated elements is
considered acceptable and appropriate for Emacs.

Re: solarized

[Richard Stallman]

[[[ 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. ]]]

  > But we would need the help of the theme author to ensure that copyright
  > assignments are in order before it could be included in vanilla.  Maybe
  > someone interested in that could help look into it.

To the extent that the color choices of Solarized are _determined_ by
abstracted design goals, they are not copyrightable choices.  Only
details of expression that could have been chosen differently are
copyrightable.  I don't know how much of that there is in Solarized.
If it is all decided based on what works well, maybe none of it is
copyrightable.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: solarized

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

>  But we would need the help of the theme author to ensure that copyright
assignments are in order before it could be included in vanilla.  Maybe
someone interested in that could help look into it.

I've signed the FSF copyright papers years ago, but keep in mind the theme
has other contributors as well.
Anyways, I'll help however I can with the copyright stuff, provided you
decide to move in that direction.

On Sat, 19 Sep 2020 at 07:02, Richard Stallman <rms@gnu.org> wrote:

> [[[ 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. ]]]
>
>   > But we would need the help of the theme author to ensure that copyright
>   > assignments are in order before it could be included in vanilla.  Maybe
>   > someone interested in that could help look into it.
>
> To the extent that the color choices of Solarized are _determined_ by
> abstracted design goals, they are not copyrightable choices.  Only
> details of expression that could have been chosen differently are
> copyrightable.  I don't know how much of that there is in Solarized.
> If it is all decided based on what works well, maybe none of it is
> copyrightable.
>
> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2123 bytes --]

WCAG AAA and Emacs themes

[Dmitry Gutov]

On 15.09.2020 11:29, Protesilaos Stavrou wrote:
> For an alternative that conforms with the WCAG AAA standard (7:1), has
> broad face/package coverage, and is highly customisable, consider either
> of the themes 'modus-operandi' (light) and 'modus-vivendi' (dark) which
> are in the Emacs master branch.  Disclosure: I am their author and will
> share their latest version, as well as an Info manual, at the end of
> this month.

I, for one, am very happy to see a theme author use an educated approach 
like that.

modus-operandi is a solid theme, very readable (though I'd probably 
tweak the colors just a bit, for personal aesthetics).

Re: WCAG AAA and Emacs themes

[Protesilaos Stavrou]

Dmitry Gutov <dgutov@yandex.ru> [2020-09-15, 15:05 +0300]:

> On 15.09.2020 11:29, Protesilaos Stavrou wrote:
>> For an alternative that conforms with the WCAG AAA standard (7:1), has
>> broad face/package coverage, and is highly customisable, consider either
>> of the themes 'modus-operandi' (light) and 'modus-vivendi' (dark) which
>> are in the Emacs master branch.  Disclosure: I am their author and will
>> share their latest version, as well as an Info manual, at the end of
>> this month.
>
> I, for one, am very happy to see a theme author use an educated
> approach like that.

I am monitoring the evolving discussions and am willing to help.
Perhaps the notion of a theme framework is the way to go.

> modus-operandi is a solid theme, very readable (though I'd probably
> tweak the colors just a bit, for personal aesthetics).

If you think those could be useful to others, please let me know.

-- 
Protesilaos Stavrou
protesilaos.com

Re: solarized

[Protesilaos Stavrou]

Arthur Miller <arthur.miller@live.com> [2020-09-16, 15:38 +0200]:

> Protesilaos Stavrou <info@protesilaos.com> writes:
>> On another note, do we really need to strictly conform with the
>> 16-colour palette?

> Batsov's Solarized gives you total of 32 colors. I certainly don't want to see
> all 32 colors at once in the gui :-). Anyway 16 of those are ment for
> extreme cases, and are just shades of eight accented colors, ligher and darker.

Agreed!  I never advocated for adding rainbows anywhere.  My point is
that the "extreme cases" that need more refined colouration are not that
uncommon after all.  And I gave specific examples, such as diffs with
word-wise changes (and Magit), isearch, occur, completion UIs.

> If those are not enough for some extreme case, user can always do what
> they do now, specify rgb value directly; but for *most* part, hopefully
> 16 colors would be enough. Nobody said it has to be enough for
> *everybody everywhere*.

That is always an option.  My impression, however, is that we are
thinking about how to improve upon the state of affairs.  One such way
is to offer more complete face/colour coverage for everyone (and they
can still configure it afterwards).  To that I also add the
accessibility angle.  Perhaps I misunderstood the intent of this
discussion, so please accept my apologies.

>> In my experience, 16 colours is too limited of a set to design bespoke,
>> usable, and pleasing interfaces that match the wide array of needs an
>> Emacs user has.
> Design literature on contrary says something in lines of "less is more",
> both when it comes to color and form.
>
> Too many colors and you get rainbow. Look at dired+ screenshot I
> attached. Every "property" is coded in different color, and it just
> looks horrible when put together.
>
> Another subject, similar to gui theme colors, is syntax highlighting. Too much
> syntax highlighting can be as detrimental as none, see for example this paper:
>
> https://pdfs.semanticscholar.org/d14b/edf3f58080ecf7a92f60746371b894a7bc08.pdf
>
> and this screenshot:
>
> https://imgur.com/zhCs4Bv
>
> Maybe some thoughts here:
>
> https://www.linusakesson.net/programming/syntaxhighlighting/

These are all interesting and fecund.  A good design must avoid
exaggerations, rainbow effects, and design for its own sake.

This, however, is an indictment against poorly implemented themes,
though not extended colour palettes as such.  Your attached screenshot
uses what looks like ~14 colours.

-- 
Protesilaos Stavrou
protesilaos.com

Re: solarized

[Arthur Miller]

Protesilaos Stavrou <info@protesilaos.com> writes:


>> If those are not enough for some extreme case, user can always do what
>> they do now, specify rgb value directly; but for *most* part, hopefully
>> 16 colors would be enough. Nobody said it has to be enough for
>> *everybody everywhere*.
>
> That is always an option.  My impression, however, is that we are
> thinking about how to improve upon the state of affairs.  One such way
> is to offer more complete face/colour coverage for everyone (and they
> can still configure it afterwards).  To that I also add the
> accessibility angle.  Perhaps I misunderstood the intent of this
> discussion, so please accept my apologies.
No need to apologize, I tottaly understand you; I am not trying to be
hars or personal either. I am just trying to say that it is probably
impossible to aim to give a solution that will always work for everyone.
I think it is usually good enough to give a solution that work for the
most of people most of the time.

Another solution, instead of solarized way of thinking (base & accented
colors), would be to give an array such as base16 theme generator does
(linked in some other mail in the discussion), and guide users to think
in terms of: use "upper part" of colors for base elements (gui
background, fg, etc), use lower part for accent colors in order of
importance (just as an idea). The array could be as much as 256 if
number of colors is needed, but I still think 16~32 would do :-).

The most important part is not number of colors, but framework so
everyone, Emacs internals as well as third party packages use same
parametrized names for colors (or faces as corrected by Thomas).


> These are all interesting and fecund.  A good design must avoid
> exaggerations, rainbow effects, and design for its own sake.
>
> This, however, is an indictment against poorly implemented themes,
> though not extended colour palettes as such.  Your attached screenshot
> uses what looks like ~14 colours.
Indeed! For the 99% of 3rd party packages (might be an exaggaration
:-)), default foreground color is probably what they should use but
programmers believe they have to color code every property differently
and we get things to look as they do.

Maybe some of such design issues can be avoided if there was a
framework and user guide telling people something in line:

Use base-1~base-N for the colors of main elements (mostly theme creators
would care about those); use accent-1 ~ accent-N if you wish your text
to stand out in the GUI. Then give them a limited number of colors to
use and they might use color coding more sparingly. If the given amount
of colors is not enough they can always go into rgb valley and pick
some, but probably less will do so then what they do now. (I have no
scientific proof, just my opinion :-)).

Re: solarized

[Arthur Miller]

Protesilaos Stavrou <info@protesilaos.com> writes:

>                                    A good design must avoid
> exaggerations, rainbow effects, and design for its own sake.
>
> This, however, is an indictment against poorly implemented themes,
> though not extended colour palettes as such.
If you are interested in colors in design, I can recommend a good book,

"Design Elements: Color Fundamentals" by Aaris Sherin, it is relatively
recent book (2012) and in my opinion nicely written and good
introduction into color theory and design without being overy
"technical" and with lots of modern illustrations.

You can probably make a distance loan through your city or university
library (don't know how it works in Greece, but I guess similar as in
rest of EU).

Otherwise search on Joseph Albers and Johannes Itten. Itten's book "The
Elements of Color" is now out of copyright I think, since it is very
old, so it is maybe possible to find it on the web for free; but I would
suggest Sherin.