* solarized @ 2020-09-14 3:48 Richard Stallman 2020-09-15 8:29 ` solarized Protesilaos Stavrou 0 siblings, 1 reply; 48+ messages in thread From: Richard Stallman @ 2020-09-14 3:48 UTC (permalink / raw) To: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-14 3:48 solarized Richard Stallman @ 2020-09-15 8:29 ` Protesilaos Stavrou 2020-09-15 9:14 ` solarized Yuri Khan ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Protesilaos Stavrou @ 2020-09-15 8:29 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-15 8:29 ` solarized Protesilaos Stavrou @ 2020-09-15 9:14 ` Yuri Khan 2020-09-15 10:16 ` solarized Protesilaos Stavrou 2020-09-15 11:26 ` solarized Göktuğ Kayaalp 2020-09-15 12:05 ` WCAG AAA and Emacs themes Dmitry Gutov 2 siblings, 1 reply; 48+ messages in thread From: Yuri Khan @ 2020-09-15 9:14 UTC (permalink / raw) To: Protesilaos Stavrou; +Cc: Richard Stallman, Emacs developers 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.) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-15 9:14 ` solarized Yuri Khan @ 2020-09-15 10:16 ` Protesilaos Stavrou 2020-09-15 13:39 ` solarized Theodor Thornhill 2020-09-16 5:05 ` solarized Richard Stallman 0 siblings, 2 replies; 48+ messages in thread From: Protesilaos Stavrou @ 2020-09-15 10:16 UTC (permalink / raw) To: Yuri Khan; +Cc: Richard Stallman, Emacs developers 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-15 10:16 ` solarized Protesilaos Stavrou @ 2020-09-15 13:39 ` Theodor Thornhill 2020-09-15 14:05 ` solarized Gerry Agbobada 2020-09-15 20:28 ` solarized Protesilaos Stavrou 2020-09-16 5:05 ` solarized Richard Stallman 1 sibling, 2 replies; 48+ messages in thread From: Theodor Thornhill @ 2020-09-15 13:39 UTC (permalink / raw) To: emacs-devel, Protesilaos Stavrou, Yuri Khan Cc: Richard Stallman, Emacs developers 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-15 13:39 ` solarized Theodor Thornhill @ 2020-09-15 14:05 ` Gerry Agbobada 2020-09-15 14:40 ` Theme generator (was: solarized) Stefan Monnier 2020-09-15 20:28 ` solarized Protesilaos Stavrou 1 sibling, 1 reply; 48+ messages in thread From: Gerry Agbobada @ 2020-09-15 14:05 UTC (permalink / raw) To: Gregory Heytings via Emacs development discussions. [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Theme generator (was: solarized) 2020-09-15 14:05 ` solarized Gerry Agbobada @ 2020-09-15 14:40 ` Stefan Monnier 2020-09-15 16:26 ` Theme generator Arthur Miller ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Stefan Monnier @ 2020-09-15 14:40 UTC (permalink / raw) To: Gerry Agbobada; +Cc: Gregory Heytings via Emacs development discussions. > 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Theme generator 2020-09-15 14:40 ` Theme generator (was: solarized) Stefan Monnier @ 2020-09-15 16:26 ` Arthur Miller 2020-09-15 20:14 ` Stefan Monnier 2020-09-16 1:49 ` Theme generator (was: solarized) Tim Cross 2020-09-16 5:03 ` Theme generator (was: solarized) Richard Stallman 2 siblings, 1 reply; 48+ messages in thread From: Arthur Miller @ 2020-09-15 16:26 UTC (permalink / raw) To: Stefan Monnier Cc: Gerry Agbobada, Gregory Heytings via Emacs development discussions. 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). ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Theme generator 2020-09-15 16:26 ` Theme generator Arthur Miller @ 2020-09-15 20:14 ` Stefan Monnier 2020-09-15 20:35 ` Stefan Monnier 0 siblings, 1 reply; 48+ messages in thread From: Stefan Monnier @ 2020-09-15 20:14 UTC (permalink / raw) To: Arthur Miller Cc: Gerry Agbobada, Gregory Heytings via Emacs development discussions. >> 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Theme generator 2020-09-15 20:14 ` Stefan Monnier @ 2020-09-15 20:35 ` Stefan Monnier 2020-09-15 20:44 ` Arthur Miller 0 siblings, 1 reply; 48+ messages in thread From: Stefan Monnier @ 2020-09-15 20:35 UTC (permalink / raw) To: Arthur Miller Cc: Gerry Agbobada, Gregory Heytings via Emacs development discussions. > 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Theme generator 2020-09-15 20:35 ` Stefan Monnier @ 2020-09-15 20:44 ` Arthur Miller 0 siblings, 0 replies; 48+ messages in thread From: Arthur Miller @ 2020-09-15 20:44 UTC (permalink / raw) To: Stefan Monnier Cc: Gerry Agbobada, Gregory Heytings via Emacs development discussions. 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Theme generator (was: solarized) 2020-09-15 14:40 ` Theme generator (was: solarized) Stefan Monnier 2020-09-15 16:26 ` Theme generator Arthur Miller @ 2020-09-16 1:49 ` Tim Cross 2020-09-17 0:25 ` chad 2020-09-16 5:03 ` Theme generator (was: solarized) Richard Stallman 2 siblings, 1 reply; 48+ messages in thread From: Tim Cross @ 2020-09-16 1:49 UTC (permalink / raw) To: Stefan Monnier Cc: Gerry Agbobada, Gregory Heytings via Emacs development discussions. [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Theme generator (was: solarized) 2020-09-16 1:49 ` Theme generator (was: solarized) Tim Cross @ 2020-09-17 0:25 ` chad 2020-09-17 14:25 ` Theme generator Arthur Miller 0 siblings, 1 reply; 48+ messages in thread From: chad @ 2020-09-17 0:25 UTC (permalink / raw) To: Tim Cross Cc: Gerry Agbobada, Stefan Monnier, Gregory Heytings via Emacs development discussions. [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Theme generator 2020-09-17 0:25 ` chad @ 2020-09-17 14:25 ` Arthur Miller 0 siblings, 0 replies; 48+ messages in thread From: Arthur Miller @ 2020-09-17 14:25 UTC (permalink / raw) To: chad Cc: Gerry Agbobada, Tim Cross, Stefan Monnier, Gregory Heytings via Emacs development discussions. 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). ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: Theme generator (was: solarized) 2020-09-15 14:40 ` Theme generator (was: solarized) Stefan Monnier 2020-09-15 16:26 ` Theme generator Arthur Miller 2020-09-16 1:49 ` Theme generator (was: solarized) Tim Cross @ 2020-09-16 5:03 ` Richard Stallman 2 siblings, 0 replies; 48+ messages in thread From: Richard Stallman @ 2020-09-16 5:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-15 13:39 ` solarized Theodor Thornhill 2020-09-15 14:05 ` solarized Gerry Agbobada @ 2020-09-15 20:28 ` Protesilaos Stavrou 2020-09-15 20:50 ` solarized Praharsh Suryadevara 1 sibling, 1 reply; 48+ messages in thread From: Protesilaos Stavrou @ 2020-09-15 20:28 UTC (permalink / raw) To: Theodor Thornhill; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-15 20:28 ` solarized Protesilaos Stavrou @ 2020-09-15 20:50 ` Praharsh Suryadevara 0 siblings, 0 replies; 48+ messages in thread From: Praharsh Suryadevara @ 2020-09-15 20:50 UTC (permalink / raw) To: Protesilaos Stavrou; +Cc: Theodor Thornhill, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-15 10:16 ` solarized Protesilaos Stavrou 2020-09-15 13:39 ` solarized Theodor Thornhill @ 2020-09-16 5:05 ` Richard Stallman 2020-09-16 8:27 ` solarized Protesilaos Stavrou 2020-09-16 13:06 ` solarized Arthur Miller 1 sibling, 2 replies; 48+ messages in thread From: Richard Stallman @ 2020-09-16 5:05 UTC (permalink / raw) To: Protesilaos Stavrou; +Cc: emacs-devel, yuri.v.khan [[[ 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) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-16 5:05 ` solarized Richard Stallman @ 2020-09-16 8:27 ` Protesilaos Stavrou 2020-09-16 13:38 ` solarized Arthur Miller 2020-09-17 3:57 ` solarized Richard Stallman 2020-09-16 13:06 ` solarized Arthur Miller 1 sibling, 2 replies; 48+ messages in thread From: Protesilaos Stavrou @ 2020-09-16 8:27 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-16 8:27 ` solarized Protesilaos Stavrou @ 2020-09-16 13:38 ` Arthur Miller 2020-09-17 3:57 ` solarized Richard Stallman 1 sibling, 0 replies; 48+ messages in thread From: Arthur Miller @ 2020-09-16 13:38 UTC (permalink / raw) To: Protesilaos Stavrou; +Cc: Richard Stallman, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-16 8:27 ` solarized Protesilaos Stavrou 2020-09-16 13:38 ` solarized Arthur Miller @ 2020-09-17 3:57 ` Richard Stallman 2020-09-17 7:53 ` solarized Gian Uberto Lauri 2020-09-17 14:11 ` solarized Arthur Miller 1 sibling, 2 replies; 48+ messages in thread From: Richard Stallman @ 2020-09-17 3:57 UTC (permalink / raw) To: Protesilaos Stavrou; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-17 3:57 ` solarized Richard Stallman @ 2020-09-17 7:53 ` Gian Uberto Lauri 2020-09-17 15:56 ` solarized Drew Adams ` (2 more replies) 2020-09-17 14:11 ` solarized Arthur Miller 1 sibling, 3 replies; 48+ messages in thread From: Gian Uberto Lauri @ 2020-09-17 7:53 UTC (permalink / raw) To: emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: solarized 2020-09-17 7:53 ` solarized Gian Uberto Lauri @ 2020-09-17 15:56 ` Drew Adams 2020-09-18 4:08 ` solarized Richard Stallman 2020-09-18 4:08 ` solarized Richard Stallman 2 siblings, 0 replies; 48+ messages in thread From: Drew Adams @ 2020-09-17 15:56 UTC (permalink / raw) To: Gian Uberto Lauri, emacs-devel > 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-17 7:53 ` solarized Gian Uberto Lauri 2020-09-17 15:56 ` solarized Drew Adams @ 2020-09-18 4:08 ` Richard Stallman 2020-09-18 4:08 ` solarized Richard Stallman 2 siblings, 0 replies; 48+ messages in thread From: Richard Stallman @ 2020-09-18 4:08 UTC (permalink / raw) To: Gian Uberto Lauri; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-17 7:53 ` solarized Gian Uberto Lauri 2020-09-17 15:56 ` solarized Drew Adams 2020-09-18 4:08 ` solarized Richard Stallman @ 2020-09-18 4:08 ` Richard Stallman 2020-09-18 16:44 ` solarized Drew Adams 2 siblings, 1 reply; 48+ messages in thread From: Richard Stallman @ 2020-09-18 4:08 UTC (permalink / raw) To: Gian Uberto Lauri; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: solarized 2020-09-18 4:08 ` solarized Richard Stallman @ 2020-09-18 16:44 ` Drew Adams 0 siblings, 0 replies; 48+ messages in thread From: Drew Adams @ 2020-09-18 16:44 UTC (permalink / raw) To: rms, Gian Uberto Lauri; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-17 3:57 ` solarized Richard Stallman 2020-09-17 7:53 ` solarized Gian Uberto Lauri @ 2020-09-17 14:11 ` Arthur Miller 2020-09-17 23:39 ` solarized Tim Cross 1 sibling, 1 reply; 48+ messages in thread From: Arthur Miller @ 2020-09-17 14:11 UTC (permalink / raw) To: Richard Stallman; +Cc: Protesilaos Stavrou, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-17 14:11 ` solarized Arthur Miller @ 2020-09-17 23:39 ` Tim Cross 2020-09-18 4:13 ` solarized Richard Stallman 0 siblings, 1 reply; 48+ messages in thread From: Tim Cross @ 2020-09-17 23:39 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-17 23:39 ` solarized Tim Cross @ 2020-09-18 4:13 ` Richard Stallman 2020-09-18 5:49 ` solarized Tim Cross 2020-09-18 6:43 ` solarized Arthur Miller 0 siblings, 2 replies; 48+ messages in thread From: Richard Stallman @ 2020-09-18 4:13 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-18 4:13 ` solarized Richard Stallman @ 2020-09-18 5:49 ` Tim Cross 2020-09-18 6:43 ` solarized Arthur Miller 1 sibling, 0 replies; 48+ messages in thread From: Tim Cross @ 2020-09-18 5:49 UTC (permalink / raw) To: rms; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-18 4:13 ` solarized Richard Stallman 2020-09-18 5:49 ` solarized Tim Cross @ 2020-09-18 6:43 ` Arthur Miller 1 sibling, 0 replies; 48+ messages in thread From: Arthur Miller @ 2020-09-18 6:43 UTC (permalink / raw) To: Richard Stallman; +Cc: Tim Cross, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-16 5:05 ` solarized Richard Stallman 2020-09-16 8:27 ` solarized Protesilaos Stavrou @ 2020-09-16 13:06 ` Arthur Miller 2020-09-17 3:53 ` solarized Richard Stallman 1 sibling, 1 reply; 48+ messages in thread From: Arthur Miller @ 2020-09-16 13:06 UTC (permalink / raw) To: Richard Stallman; +Cc: Protesilaos Stavrou, yuri.v.khan, emacs-devel 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 :-). ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-16 13:06 ` solarized Arthur Miller @ 2020-09-17 3:53 ` Richard Stallman 0 siblings, 0 replies; 48+ messages in thread From: Richard Stallman @ 2020-09-17 3:53 UTC (permalink / raw) To: Arthur Miller; +Cc: info, emacs-devel, yuri.v.khan [[[ 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) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-15 8:29 ` solarized Protesilaos Stavrou 2020-09-15 9:14 ` solarized Yuri Khan @ 2020-09-15 11:26 ` Göktuğ Kayaalp 2020-09-15 12:15 ` solarized Elias Mårtenson 2020-09-15 12:05 ` WCAG AAA and Emacs themes Dmitry Gutov 2 siblings, 1 reply; 48+ messages in thread From: Göktuğ Kayaalp @ 2020-09-15 11:26 UTC (permalink / raw) To: emacs-devel; +Cc: Richard Stallman 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-15 11:26 ` solarized Göktuğ Kayaalp @ 2020-09-15 12:15 ` Elias Mårtenson 2020-09-15 12:56 ` solarized Göktuğ Kayaalp 0 siblings, 1 reply; 48+ messages in thread From: Elias Mårtenson @ 2020-09-15 12:15 UTC (permalink / raw) To: Göktuğ Kayaalp; +Cc: Richard Stallman, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-15 12:15 ` solarized Elias Mårtenson @ 2020-09-15 12:56 ` Göktuğ Kayaalp 2020-09-16 1:30 ` solarized Tim Cross 0 siblings, 1 reply; 48+ messages in thread From: Göktuğ Kayaalp @ 2020-09-15 12:56 UTC (permalink / raw) To: Elias Mårtenson Cc: Göktuğ Kayaalp, Richard Stallman, emacs-devel 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-15 12:56 ` solarized Göktuğ Kayaalp @ 2020-09-16 1:30 ` Tim Cross 2020-09-16 10:21 ` solarized Göktuğ Kayaalp 0 siblings, 1 reply; 48+ messages in thread From: Tim Cross @ 2020-09-16 1:30 UTC (permalink / raw) To: Göktuğ Kayaalp Cc: Elias Mårtenson, Richard Stallman, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-16 1:30 ` solarized Tim Cross @ 2020-09-16 10:21 ` Göktuğ Kayaalp 2020-09-16 12:53 ` solarized Arthur Miller 2020-09-16 22:09 ` solarized Tim Cross 0 siblings, 2 replies; 48+ messages in thread From: Göktuğ Kayaalp @ 2020-09-16 10:21 UTC (permalink / raw) To: Tim Cross Cc: Göktuğ Kayaalp, Elias Mårtenson, Richard Stallman, emacs-devel 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-16 10:21 ` solarized Göktuğ Kayaalp @ 2020-09-16 12:53 ` Arthur Miller 2020-09-16 22:09 ` solarized Tim Cross 1 sibling, 0 replies; 48+ messages in thread From: Arthur Miller @ 2020-09-16 12:53 UTC (permalink / raw) To: Göktuğ Kayaalp Cc: Tim Cross, Elias Mårtenson, Richard Stallman, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-16 10:21 ` solarized Göktuğ Kayaalp 2020-09-16 12:53 ` solarized Arthur Miller @ 2020-09-16 22:09 ` Tim Cross 2020-09-17 14:29 ` solarized Arthur Miller 2020-09-18 13:32 ` solarized Stefan Kangas 1 sibling, 2 replies; 48+ messages in thread From: Tim Cross @ 2020-09-16 22:09 UTC (permalink / raw) To: Göktuğ Kayaalp Cc: Elias Mårtenson, Richard Stallman, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-16 22:09 ` solarized Tim Cross @ 2020-09-17 14:29 ` Arthur Miller 2020-09-18 13:32 ` solarized Stefan Kangas 1 sibling, 0 replies; 48+ messages in thread From: Arthur Miller @ 2020-09-17 14:29 UTC (permalink / raw) To: Tim Cross Cc: Göktuğ Kayaalp, Elias Mårtenson, Richard Stallman, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-16 22:09 ` solarized Tim Cross 2020-09-17 14:29 ` solarized Arthur Miller @ 2020-09-18 13:32 ` Stefan Kangas 2020-09-18 15:53 ` solarized Arthur Miller ` (2 more replies) 1 sibling, 3 replies; 48+ messages in thread From: Stefan Kangas @ 2020-09-18 13:32 UTC (permalink / raw) To: Tim Cross, Göktuğ Kayaalp Cc: Elias Mårtenson, Richard Stallman, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-18 13:32 ` solarized Stefan Kangas @ 2020-09-18 15:53 ` Arthur Miller 2020-09-18 16:03 ` solarized Arthur Miller 2020-09-19 4:00 ` solarized Richard Stallman 2 siblings, 0 replies; 48+ messages in thread From: Arthur Miller @ 2020-09-18 15:53 UTC (permalink / raw) To: Stefan Kangas Cc: Göktuğ Kayaalp, Tim Cross, Elias Mårtenson, Richard Stallman, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-18 13:32 ` solarized Stefan Kangas 2020-09-18 15:53 ` solarized Arthur Miller @ 2020-09-18 16:03 ` Arthur Miller 2020-09-19 4:00 ` solarized Richard Stallman 2 siblings, 0 replies; 48+ messages in thread From: Arthur Miller @ 2020-09-18 16:03 UTC (permalink / raw) To: Stefan Kangas Cc: Göktuğ Kayaalp, Tim Cross, Elias Mårtenson, Richard Stallman, emacs-devel 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-18 13:32 ` solarized Stefan Kangas 2020-09-18 15:53 ` solarized Arthur Miller 2020-09-18 16:03 ` solarized Arthur Miller @ 2020-09-19 4:00 ` Richard Stallman 2020-09-20 20:18 ` solarized Bozhidar Batsov 2 siblings, 1 reply; 48+ messages in thread From: Richard Stallman @ 2020-09-19 4:00 UTC (permalink / raw) To: Stefan Kangas; +Cc: self, theophilusx, lokedhs, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: solarized 2020-09-19 4:00 ` solarized Richard Stallman @ 2020-09-20 20:18 ` Bozhidar Batsov 0 siblings, 0 replies; 48+ messages in thread From: Bozhidar Batsov @ 2020-09-20 20:18 UTC (permalink / raw) To: rms; +Cc: self, theophilusx, lokedhs, Stefan Kangas, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* WCAG AAA and Emacs themes 2020-09-15 8:29 ` solarized Protesilaos Stavrou 2020-09-15 9:14 ` solarized Yuri Khan 2020-09-15 11:26 ` solarized Göktuğ Kayaalp @ 2020-09-15 12:05 ` Dmitry Gutov 2020-09-15 20:22 ` Protesilaos Stavrou 2 siblings, 1 reply; 48+ messages in thread From: Dmitry Gutov @ 2020-09-15 12:05 UTC (permalink / raw) To: Protesilaos Stavrou, Richard Stallman; +Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: WCAG AAA and Emacs themes 2020-09-15 12:05 ` WCAG AAA and Emacs themes Dmitry Gutov @ 2020-09-15 20:22 ` Protesilaos Stavrou 0 siblings, 0 replies; 48+ messages in thread From: Protesilaos Stavrou @ 2020-09-15 20:22 UTC (permalink / raw) To: Dmitry Gutov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2020-09-20 20:18 UTC | newest] Thread overview: 48+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-09-14 3:48 solarized Richard Stallman 2020-09-15 8:29 ` solarized Protesilaos Stavrou 2020-09-15 9:14 ` solarized Yuri Khan 2020-09-15 10:16 ` solarized Protesilaos Stavrou 2020-09-15 13:39 ` solarized Theodor Thornhill 2020-09-15 14:05 ` solarized Gerry Agbobada 2020-09-15 14:40 ` Theme generator (was: solarized) Stefan Monnier 2020-09-15 16:26 ` Theme generator Arthur Miller 2020-09-15 20:14 ` Stefan Monnier 2020-09-15 20:35 ` Stefan Monnier 2020-09-15 20:44 ` Arthur Miller 2020-09-16 1:49 ` Theme generator (was: solarized) Tim Cross 2020-09-17 0:25 ` chad 2020-09-17 14:25 ` Theme generator Arthur Miller 2020-09-16 5:03 ` Theme generator (was: solarized) Richard Stallman 2020-09-15 20:28 ` solarized Protesilaos Stavrou 2020-09-15 20:50 ` solarized Praharsh Suryadevara 2020-09-16 5:05 ` solarized Richard Stallman 2020-09-16 8:27 ` solarized Protesilaos Stavrou 2020-09-16 13:38 ` solarized Arthur Miller 2020-09-17 3:57 ` solarized Richard Stallman 2020-09-17 7:53 ` solarized Gian Uberto Lauri 2020-09-17 15:56 ` solarized Drew Adams 2020-09-18 4:08 ` solarized Richard Stallman 2020-09-18 4:08 ` solarized Richard Stallman 2020-09-18 16:44 ` solarized Drew Adams 2020-09-17 14:11 ` solarized Arthur Miller 2020-09-17 23:39 ` solarized Tim Cross 2020-09-18 4:13 ` solarized Richard Stallman 2020-09-18 5:49 ` solarized Tim Cross 2020-09-18 6:43 ` solarized Arthur Miller 2020-09-16 13:06 ` solarized Arthur Miller 2020-09-17 3:53 ` solarized Richard Stallman 2020-09-15 11:26 ` solarized Göktuğ Kayaalp 2020-09-15 12:15 ` solarized Elias Mårtenson 2020-09-15 12:56 ` solarized Göktuğ Kayaalp 2020-09-16 1:30 ` solarized Tim Cross 2020-09-16 10:21 ` solarized Göktuğ Kayaalp 2020-09-16 12:53 ` solarized Arthur Miller 2020-09-16 22:09 ` solarized Tim Cross 2020-09-17 14:29 ` solarized Arthur Miller 2020-09-18 13:32 ` solarized Stefan Kangas 2020-09-18 15:53 ` solarized Arthur Miller 2020-09-18 16:03 ` solarized Arthur Miller 2020-09-19 4:00 ` solarized Richard Stallman 2020-09-20 20:18 ` solarized Bozhidar Batsov 2020-09-15 12:05 ` WCAG AAA and Emacs themes Dmitry Gutov 2020-09-15 20:22 ` Protesilaos Stavrou
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.