Darkening font-lock colors

Darkening font-lock colors

[Chong Yidong]

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

While doing some testing, I went back to the default white background,
and noticed that some of the font-lock colors have rather poor contrast.
I'm not sure if this is partly due to anti-aliasing, but it sure makes
the text difficult to read.

What do people think about making the following changes for the
light-background settings?

 font-lock-builtin-face:  "LightGray" -> "MediumOrchid4"
 font-lock-constant-face: "CadetBlue" -> "dark cyan"
 font-lock-string-face:   "RosyBrown" -> "VioletRed4"
 font-lock-variable-name-face: "DarkGoldenrod" -> "OrangeRed4"

This does not alter the existing color scheme, except for darkening the
fainter colors.  (The dark-background color scheme seems to be fine.)


[-- Attachment #2: font-lock-colors.png --]
[-- Type: image/png, Size: 31368 bytes --]

Re: Darkening font-lock colors

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > While doing some testing, I went back to the default white background,
  > and noticed that some of the font-lock colors have rather poor contrast.
  > I'm not sure if this is partly due to anti-aliasing, but it sure makes
  > the text difficult to read.
  > 
  > What do people think about making the following changes for the
  > light-background settings?
  > 
  >  font-lock-builtin-face:  "LightGray" -> "MediumOrchid4"
  >  font-lock-constant-face: "CadetBlue" -> "dark cyan"
  >  font-lock-string-face:   "RosyBrown" -> "VioletRed4"
  >  font-lock-variable-name-face: "DarkGoldenrod" -> "OrangeRed4"
  > 
  > This does not alter the existing color scheme, except for darkening the
  > fainter colors.  (The dark-background color scheme seems to be fine.)

What do they look on a light gray background?  While not the default,
many people use a light gray background (like gray91) because white is
too bright.

Re: Darkening font-lock colors

[Lennart Borgman]

On Thu, Jul 30, 2009 at 11:12 PM, Chong Yidong<cyd@stupidchicken.com> wrote:
> While doing some testing, I went back to the default white background,
> and noticed that some of the font-lock colors have rather poor contrast.
> I'm not sure if this is partly due to anti-aliasing, but it sure makes
> the text difficult to read.
>
> What do people think about making the following changes for the
> light-background settings?
>
>  font-lock-builtin-face:  "LightGray" -> "MediumOrchid4"
>  font-lock-constant-face: "CadetBlue" -> "dark cyan"
>  font-lock-string-face:   "RosyBrown" -> "VioletRed4"
>  font-lock-variable-name-face: "DarkGoldenrod" -> "OrangeRed4"
>
> This does not alter the existing color scheme, except for darkening the
> fainter colors.  (The dark-background color scheme seems to be fine.)


I think the colors becomes to similar with your change.

I have no problems with the existing colors. Are you using a white background?

RE: Darkening font-lock colors

[Drew Adams]

> What do they look on a light gray background?  While not the default,
> many people use a light gray background (like gray91) because white is
> too bright.

Agreed. Or another light background (like LightBlue). 

Re: Darkening font-lock colors

[Chong Yidong]

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

Dan Nicolaescu <dann@ics.uci.edu> writes:

>   > This does not alter the existing color scheme, except for darkening the
>   > fainter colors.  (The dark-background color scheme seems to be fine.)
>
> What do they look on a light gray background?  While not the default,
> many people use a light gray background (like gray91) because white is
> too bright.

See attached.  One a LightGray background, font-lock-string-face is
almost illegible by default IMO.


[-- Attachment #2: font-lock-colors2.png --]
[-- Type: image/png, Size: 21283 bytes --]

Re: Darkening font-lock colors

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

>> What do they look on a light gray background?  While not the default,
>> many people use a light gray background (like gray91) because white is
>> too bright.
>
> Agreed. Or another light background (like LightBlue).

As a rule, if the color contrast is too low for white backgrounds, it
will be even worse for other light backgrounds.

Re: Darkening font-lock colors

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > >   > This does not alter the existing color scheme, except for darkening the
  > >   > fainter colors.  (The dark-background color scheme seems to be fine.)
  > >
  > > What do they look on a light gray background?  While not the default,
  > > many people use a light gray background (like gray91) because white is
  > > too bright.
  > 
  > See attached.  One a LightGray background, font-lock-string-face is
  > almost illegible by default IMO.

I see no reason to change font-lock-variable-name-face, seems readable
enough, and its too similar to font-lock-string-face after the change.

Maybe font-lock-string-face could use some change.

I don't have a problem with the current colors for the rest of the
faces...

Please also test on a 256 color xterm (with both white and light gray
background), the colors are very very similar, but not all are
completely identical...

Re: Darkening font-lock colors

[Deniz Dogan]

2009/7/30 Chong Yidong <cyd@stupidchicken.com>:
> While doing some testing, I went back to the default white background,
> and noticed that some of the font-lock colors have rather poor contrast.
> I'm not sure if this is partly due to anti-aliasing, but it sure makes
> the text difficult to read.
>
> What do people think about making the following changes for the
> light-background settings?
>
>  font-lock-builtin-face:  "LightGray" -> "MediumOrchid4"
>  font-lock-constant-face: "CadetBlue" -> "dark cyan"
>  font-lock-string-face:   "RosyBrown" -> "VioletRed4"
>  font-lock-variable-name-face: "DarkGoldenrod" -> "OrangeRed4"
>
> This does not alter the existing color scheme, except for darkening the
> fainter colors.  (The dark-background color scheme seems to be fine.)
>

I agree that the current faces are a bit too bright and I'm in favor
of this change. Someone said that the colors become too similar to one
another with this change, but I don't agree. Also, the "problem" of
too similar-looking faces already exists anyways, e.g.
font-lock-preprocessor-face vs. font-lock-builtin-face or
font-lock-doc-face vs. font-lock-string-face. It is more important to
be able to see the actual text than having different faces for
different kinds of text.

As a side note, I don't think many people would even notice this
change unless they were explicitly told about it.

-- 
Deniz Dogan

Re: Darkening font-lock colors

[David De La Harpe Golden]

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

Dan Nicolaescu wrote:

>   > See attached.  One a LightGray background, font-lock-string-face is
>   > almost illegible by default IMO.
> 
> I see no reason to change font-lock-variable-name-face, seems readable
> enough, and its too similar to font-lock-string-face after the change.
> 

Best also bear in mind people's (especially males) color perception 
ability can vary. I fed the provided sample through the color-blindness 
display filters in GIMP (couldn't work out how to save other than screen 
capture, blargh, display filters don't work like image filters), FWIW 
(which mightn't be much, really need real color-blind people...)








[-- Attachment #2: font-lock-colors2-protanopia-gimp.png --]
[-- Type: image/png, Size: 24807 bytes --]

[-- Attachment #3: font-lock-colors2-deuteranopia-gimp.png --]
[-- Type: image/png, Size: 23069 bytes --]

[-- Attachment #4: font-lock-colors2-tritanopia-gimp.png --]
[-- Type: image/png, Size: 23234 bytes --]

Re: Darkening font-lock colors

[Lennart Borgman]

On Fri, Jul 31, 2009 at 1:40 AM, David De La Harpe
Golden<david@harpegolden.net> wrote:
> Dan Nicolaescu wrote:
>
>>  > See attached.  One a LightGray background, font-lock-string-face is
>>  > almost illegible by default IMO.
>>
>> I see no reason to change font-lock-variable-name-face, seems readable
>> enough, and its too similar to font-lock-string-face after the change.
>>
>
> Best also bear in mind people's (especially males) color perception ability
> can vary. I fed the provided sample through the color-blindness display
> filters in GIMP (couldn't work out how to save other than screen capture,
> blargh, display filters don't work like image filters), FWIW (which mightn't
> be much, really need real color-blind people...)


Great. I didn'
t know GIMP had such information.

However it seems impossible to take care of this in the default color
scheme. I suggest adding additional color schemes for the font-lock
faces for this.

Other useful things is guidelines for accessibility, for example this one here:

  http://juicystudio.com/services/csstest.php

I just mailed the author of this page and asked if he had some advice
for how to get both contrast to the background and distinguishable
colors (no response yet).


BTW, in mumamo.el I use background colors to distinguish chunks with
different major modes. I just noticed that someone with vision
impairement had problems with that. (This is problematic since the
information provided by the background color is important so I then
added a second solution for this, using the margins instead.)

Re: Darkening font-lock colors

[Lennart Borgman]

On Thu, Jul 30, 2009 at 11:39 PM, Dan Nicolaescu<dann@ics.uci.edu> wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
>
>  > While doing some testing, I went back to the default white background,
>  > and noticed that some of the font-lock colors have rather poor contrast.
>  > I'm not sure if this is partly due to anti-aliasing, but it sure makes
>  > the text difficult to read.
>  >
>  > What do people think about making the following changes for the
>  > light-background settings?
>  >
>  >  font-lock-builtin-face:  "LightGray" -> "MediumOrchid4"
>  >  font-lock-constant-face: "CadetBlue" -> "dark cyan"
>  >  font-lock-string-face:   "RosyBrown" -> "VioletRed4"
>  >  font-lock-variable-name-face: "DarkGoldenrod" -> "OrangeRed4"
>  >
>  > This does not alter the existing color scheme, except for darkening the
>  > fainter colors.  (The dark-background color scheme seems to be fine.)
>
> What do they look on a light gray background?  While not the default,
> many people use a light gray background (like gray91) because white is
> too bright.

Note: The color named LightGray is rather dark and it seems hard to
take care of that background as "light background". I think gray91 is
also a bit dark, see below for why.

   LightGray = #d3d3d3
   gray91 = #e8e8e8

For a comparision I have used these two background colors for the
first two chunk levels in mumamo.el:

   cornsilk = #fff8dc
   azure =#f0ffff

I saw a complaint by someone who is visually impaired who wanted to
remove the background colors.

Both the colors above are however much lighter than gray91. They are
more like gray95 or even lighter. So I doubt we should consider
something darker than gray95 as a light background for the sake of
helping visually impaired (but I am not sure).

Re: Darkening font-lock colors

[Chong Yidong]

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

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Please also test on a 256 color xterm (with both white and light gray
> background), the colors are very very similar, but not all are
> completely identical...

Yes, I've done that.  Results are shown.

You're right that font-lock-variable-name-face is too close to
font-lock-string-face; I swapped it with DarkOrange4, and that seems to
work better.


[-- Attachment #2: font-lock-colors3.png --]
[-- Type: image/png, Size: 6110 bytes --]

Re: Darkening font-lock colors

[Chong Yidong]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> However it seems impossible to take care of this in the default color
> scheme. I suggest adding additional color schemes for the font-lock
> faces for this.

The main goal for the default color scheme is legibility.

Re: Darkening font-lock colors

[Stefan Monnier]

> font-lock-doc-face vs. font-lock-string-face.  It is more important to
> be able to see the actual text than having different faces for
> different kinds of text.

100% agreed (most of my font-lock faces have a black foreground: they
mostly differ in bold/italics it at all).


        Stefan

Re: Darkening font-lock colors

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Please also test on a 256 color xterm (with both white and light gray
  > > background), the colors are very very similar, but not all are
  > > completely identical...
  > 
  > Yes, I've done that.  Results are shown.
  > 
  > You're right that font-lock-variable-name-face is too close to
  > font-lock-string-face; I swapped it with DarkOrange4, and that seems to
  > work better.

variable-name-face looks no better than the original, and the original
looks good, so I see no reason to change.

string-face looks better than the original

constant-face - I'm neutral about it

builtin-face is a bit too close to gray, can you please find something
with a bit more color?


Given that you are changing faces, how about changing the dark
background, 8 color font-lock-comment-face to "yellow", then we can
obsolete `font-lock-comment-delimiter-face'.

Re: Darkening font-lock colors

[Lennart Borgman]

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

On Fri, Jul 31, 2009 at 2:55 AM, Chong Yidong<cyd@stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> However it seems impossible to take care of this in the default color
>> scheme. I suggest adding additional color schemes for the font-lock
>> faces for this.
>
> The main goal for the default color scheme is legibility.

I looked a bit at the usability guidelines and wrote the attached
elisp file for testing new colors. There is an interactive function
that displays the new fonts and contrast ratios.

Testing your suggested colors I found that the contrast ratio is very
good. But it does not seem necessary to make the contrast ratio that
large as you have done. The usability guidelines suggests that a ratio
of 4.5 is enough. So there is room for colors that are more
distinguishable.

[-- Attachment #2: font-lock-color-test.el --]
[-- Type: text/plain, Size: 6349 bytes --]

;;; font-lock-color-test.el --- Tool to test new font lock colors.
;;
;; Author: Lennart Borgman (lennart O borgman A gmail O com)
;; Created: 2009-07-31 Fri
;; Last-Updated: 2009-07-31 Fri
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;; Just for testing new font lock colors. Run the command
;; `test-font-lock-colors'.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defconst test-font-lock-suggestions
  '(("chong1" ((font-lock-builtin-face "MediumOrchid4")
               (font-lock-constant-face "dark cyan")
               (font-lock-string-face  "VioletRed4")
               (font-lock-variable-name-face "OrangeRed4")))))

(defun test-font-lock-colors (suggestion)
  (interactive (list
                (completing-read "Try suggestion: "
                                 test-font-lock-suggestions
                                 nil ;; pred
                                 t   ;; require match
                                 )))
  (if (string= "" suggestion)
      (message (propertize "You did not choose any suggestion" 'face 'secondary-selection)*gensym-counter*)
    (let ((flf
           '(;; Order these so that faces that are hard to distinguish
             ;; are shown close to each other.
             font-lock-builtin-face
             font-lock-keyword-face
             font-lock-preprocessor-face

             font-lock-comment-delimiter-face
             font-lock-comment-face
             font-lock-warning-face

             font-lock-constant-face
             font-lock-type-face

             font-lock-doc-face
             font-lock-string-face
             font-lock-variable-name-face

             font-lock-function-name-face
             font-lock-negation-char-face
             font-lock-regexp-grouping-backslash
             font-lock-regexp-grouping-construct
             ))
          (buf (generate-new-buffer "Font lock face test"))
          (try-these (cadr (assoc suggestion test-font-lock-suggestions)))
          (background-color "white") ;; fix-me
          )
      (with-current-buffer buf
        (setq show-trailing-whitespace nil)
        (insert "
Faces contrast ration towards current background color. A contrast ratio higher than 4.5:1 is ok.
See for example http://www.snook.ca/technical/colour_contrast/colour.html

")
        (dolist (f flf)
          (insert
           (format "%-36s" f)
           (propertize "abcdef" 'face f)
           (let* ((try-this (assoc f try-these))
                  (new-face (cadr try-this)))
             (concat
              (if new-face
                  (concat " " (propertize "abcdef" 'face `(:foreground ,new-face)))
                "       ")
              "  "
              (display-color-contrast-ratio background-color (face-foreground f))
              "  "
              (if new-face
                  (display-color-contrast-ratio background-color new-face)
                "     "))
             )
           "\n")))
      (display-buffer buf)
      )))

;;(face-foreground 'font-lock-function-name-face)
;;(face-foreground 'font-lock-preprocessor-face)
;;(face-foreground 'font-lock-doc-face)

(defun face-foreground (face)
  (let ((color (face-attribute face :foreground))
        (inherit (face-attribute face :inherit)))
    (while (and (eq color 'unspecified)
                (not (eq inherit 'unspecified)))
      (setq face inherit)
      (setq color (face-attribute face :foreground))
      (setq inherit (face-attribute face :inherit)))
    ;; Fix-me:
    (if (eq color 'unspecified) "black" color)))

(defun relative-luminance (color-str)
  "Relative luminance of color COLOR-STR.
The relative brightness of any point in a colorspace, normalized
to 0 for darkest black and 1 for lightest white.

Note 1: For the sRGB colorspace, the relative luminance of a
color is defined as L = 0.2126 * R + 0.7152 * G + 0.0722 * B
where R, G and B are defined as:

  if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4
  if GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4
  if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4

and RsRGB, GsRGB, and BsRGB are defined as:

  RsRGB = R8bit/255
  GsRGB = G8bit/255
  BsRGB = B8bit/255

See URL `http://www.w3.org/TR/2008/REC-WCAG20-20081211/#relativeluminancedef'."
  (let* ((rgb (mapcar (lambda (val)
                        (let ((v255 (/ val 255)))
                          (if (<= v255 0.03928)
                              (/ v255 12.92)
                            (expt (/ (+ v255 0.055)
                                     1.055)
                                  2.4))))
                      (color-values color-str)))
         (r (nth 0 rgb))
         (g (nth 1 rgb))
         (b (nth 2 rgb)))
    (+ (* 0.2126 r)
       (* 0.7152 g)
       (* 0.0722 b))))

(defun luminance-contrast-ratio (l1 l2)
  "Contrast ratio between relative luminances L1 and L2.
Defined as

  (L1 + 0.05) / (L2 + 0.05)

where

  L1 is the relative luminance of the lighter of the colors, and
  L2 is the relative luminance of the darker of the colors.

See URL `http://www.w3.org/TR/2008/REC-WCAG20-20081211/#contrast-ratiodef'."
  (let* ((l-dark (if (> l1 l2) l2 l1))
         (l-bright (if (> l1 l2) l1 l2))
         (ratio (/ (+ l-bright 0.05)
                   (+ l-dark   0.05))))
    ;; Fix-me: There is something wrong in the formulas, ratio max is
    ;; 21...?
    (if (> ratio 21.0) 21.0 ratio)))

(defun color-contrast-ratio (color1 color2)
  (let ((lum1 (relative-luminance color1))
        (lum2 (relative-luminance color2)))
    (luminance-contrast-ratio lum1 lum2)))

(defun display-color-contrast-ratio (color1 color2)
  (let* ((ratio (color-contrast-ratio color1 color2))
        (str (format "%.1f" ratio)))
    (if (< ratio 4.5)
        (propertize str 'face 'font-lock-warning-face)
      str)))

;; (color-contrast-ratio "white" "DarkGoldenrod")
;; (color-contrast-ratio "white" "black")
;; (color-contrast-ratio "white" "#050505")

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; font-lock-color-test.el ends here

Re: Darkening font-lock colors

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jul 30, 2009 at 05:12:54PM -0400, Chong Yidong wrote:
> While doing some testing, I went back to the default white background,
> and noticed that some of the font-lock colors have rather poor contrast.
> I'm not sure if this is partly due to anti-aliasing, but it sure makes
> the text difficult to read.
> 
> What do people think about making the following changes for the
> light-background settings?
> 
>  font-lock-builtin-face:  "LightGray" -> "MediumOrchid4"
>  font-lock-constant-face: "CadetBlue" -> "dark cyan"
>  font-lock-string-face:   "RosyBrown" -> "VioletRed4"
>  font-lock-variable-name-face: "DarkGoldenrod" -> "OrangeRed4"

FWIW, I had exactly the same problem (especially with strong ambient
light) -- so I did similar changes:

 font-lock-string-face:        brown
 font-lock-variable-name-face: dark orange
 font-lock-comment-face:       dark blue

I seem to focus much on comments whereas I don't seem to care very much for
builtins :-)

I tried your changes and it definitely gets a +1 from me (although I'll
stick to my changes because of the comments).

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKcmrrBcgs9XrR2kYRAj5KAJ9zSpFneddjDAKeT19AMfqhcDMyBwCffrY0
XWl18GjCvh+oVfZi/qk4i4I=
=Om1T
-----END PGP SIGNATURE-----

Re: Darkening font-lock colors

[Lennart Borgman]

On Fri, Jul 31, 2009 at 5:01 AM, Lennart
Borgman<lennart.borgman@gmail.com> wrote:
> On Fri, Jul 31, 2009 at 2:55 AM, Chong Yidong<cyd@stupidchicken.com> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> However it seems impossible to take care of this in the default color
>>> scheme. I suggest adding additional color schemes for the font-lock
>>> faces for this.
>>
>> The main goal for the default color scheme is legibility.
>
> I looked a bit at the usability guidelines and wrote the attached
> elisp file for testing new colors. There is an interactive function
> that displays the new fonts and contrast ratios.


I have just uploaded a new version of my elisp file to test colors to
EmacsWiki instead of sending it here. The contrast ratios in the first
file where incorrect before (spec was wrong and I made another
mistake). I have tried to make it easier to use etc, see

  http://www.emacswiki.org/emacs/FontLockColorsAccessibility

Re: Darkening font-lock colors

[Lennart Borgman]

On Fri, Jul 31, 2009 at 5:01 AM, Lennart
Borgman<lennart.borgman@gmail.com> wrote:
> On Fri, Jul 31, 2009 at 2:55 AM, Chong Yidong<cyd@stupidchicken.com> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> However it seems impossible to take care of this in the default color
>>> scheme. I suggest adding additional color schemes for the font-lock
>>> faces for this.
>>
>> The main goal for the default color scheme is legibility.
>
> I looked a bit at the usability guidelines and wrote the attached
> elisp file for testing new colors. There is an interactive function
> that displays the new fonts and contrast ratios.
>
> Testing your suggested colors I found that the contrast ratio is very
> good. But it does not seem necessary to make the contrast ratio that
> large as you have done. The usability guidelines suggests that a ratio
> of 4.5 is enough. So there is room for colors that are more
> distinguishable.


Chong, I see that you have already installed the new colors. Could we
please try to find something better? I am not sure they look very good
(in my opinion they really don't).

Wouldn't it be good to follow the WCAG accessibility guidelines (see
file I put up here:
http://www.emacswiki.org/emacs/FontLockColorsAccessibility)? Your
suggestion have the needed contrast - but goes far above that and then
unfortunately makes the differences between the colors too small.

Unfortunately the accessibility guidelines is a bit behind when it
comes to the human distinguishability of the colors. Looking a bit at
color theory I can see this is a difficult matter if you have not got
into it. Mapping the RGB space to human percieved color differences is
something color spaces like CEILuv tries to do. I asked if someone
knew how to write the algorithms , but so far I have not got any
answer so I guess the people that are using Emacs are not that very
much into those questions. I do not really want to become an expert in
this area but the algorithms are badly described in those places where
I have found them so they can't be followed. Is there anyone who knows
a good mailing list or forum where to ask for some help about this?

Re: Darkening font-lock colors

[Chong Yidong]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Chong, I see that you have already installed the new colors. Could we
> please try to find something better? I am not sure they look very good
> (in my opinion they really don't).

Suggestions welcome.  I'm afraid I don't have the time to tinker around
finding an optimal color scheme---I just wanted to fix the legibility
problem.  If you can come up with something better, let us know.

Re: Darkening font-lock colors

[Lennart Borgman]

On Mon, Aug 3, 2009 at 12:36 AM, Chong Yidong<cyd@stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> Chong, I see that you have already installed the new colors. Could we
>> please try to find something better? I am not sure they look very good
>> (in my opinion they really don't).
>
> Suggestions welcome.  I'm afraid I don't have the time to tinker around
> finding an optimal color scheme---I just wanted to fix the legibility
> problem.  If you can come up with something better, let us know.


I did put some code together with suggestions on EmacsWiki. I am
trying to understand how to find some better choices based on color
theory, but I don't know much about it so I am trying to find someone
who knows. I got an answer from one of the GIMP developers which I am
looking into. I will come back with more information when I have had
time to understand it a bit better.

In the mean time anyone can add suggestions on that page on EmacsWiki.
The code will display those suggestions within Emacs so you can see
how it looks. It also display luminance color contrast (suggested by
WCAG).

Re: Darkening font-lock colors

[Juri Linkov]

> Suggestions welcome.  I'm afraid I don't have the time to tinker around
> finding an optimal color scheme---I just wanted to fix the legibility
> problem.  If you can come up with something better, let us know.

Thank you, finally we have legible default font-lock faces.

One problem I see is with `font-lock-string-face'.  Please look at
design guidelines for font-lock colors at the end of the Commentary
section of font-lock.el.  It says:

  Make the face attributes fit the concept as far as possible.
  i.e., function names might be a bold color such as blue, comments
  might be a bright color such as red, character strings might be brown,
  because, err, strings are brown

It seems designers chose "RosyBrown" because it contains the word "Brown".
But actually it is rosy and not brown at all.  Now we have "VioletRed4"
that it more far from brown.

Can we return the to the initial design with a color like say "RosyBrown4"?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Darkening font-lock colors

[Juri Linkov]

> Given that you are changing faces, how about changing the dark
> background, 8 color font-lock-comment-face to "yellow", then we can
> obsolete `font-lock-comment-delimiter-face'.

Why yellow?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Darkening font-lock colors

[Lennart Borgman]

On Mon, Aug 3, 2009 at 2:16 AM, Juri Linkov<juri@jurta.org> wrote:
>> Suggestions welcome.  I'm afraid I don't have the time to tinker around
>> finding an optimal color scheme---I just wanted to fix the legibility
>> problem.  If you can come up with something better, let us know.
>
> Thank you, finally we have legible default font-lock faces.
>
> One problem I see is with `font-lock-string-face'.  Please look at
> design guidelines for font-lock colors at the end of the Commentary
> section of font-lock.el.  It says:
>
>  Make the face attributes fit the concept as far as possible.
>  i.e., function names might be a bold color such as blue, comments
>  might be a bright color such as red, character strings might be brown,
>  because, err, strings are brown
>
> It seems designers chose "RosyBrown" because it contains the word "Brown".
> But actually it is rosy and not brown at all.  Now we have "VioletRed4"
> that it more far from brown.
>
> Can we return the to the initial design with a color like say "RosyBrown4"?

I think there are two essential things to cover:

- Readability, ie luminosity color contrast.
- Color distinguishability.

Making the contrast to high does not make the text more readable (if I
understand correctly) but it makes the difference between the colors
go away.

BTW, who wrote the comment? Is that Jamie Zawinski?

Re: Darkening font-lock colors

[David De La Harpe Golden]

Juri Linkov wrote:

> Can we return the to the initial design with a color like say "RosyBrown4"?
> 

Reminds me, I was going to nitpick that one of Lennart's favoured colors 
(#9C6969) was close to RosyBrown4 (#8B6969)

color-name-rgb-alist in tty-colors.el apparently contains a 
emacs-internal list of the well-known named colors (apparently leaving
out a few that have platform specific interpretations according to the
source comments), so:

(defun colored-colorlist ()
   (interactive)
   (let ((buf (get-buffer-create "*color-list*")))
     (with-current-buffer buf
       (delete-region (point-min) (point-max))
       (mapcar (lambda (l)
		(insert (format "%-20s." (car l)))
		(insert (propertize
			 (format "%-20s.\n" (car l))
			 'face (cons 'foreground-color  (car l)))))
	      color-name-rgb-alist))
     (display-buffer buf)))

Re: Darkening font-lock colors

[Lennart Borgman]

On Mon, Aug 3, 2009 at 4:14 AM, David De La Harpe
Golden<david@harpegolden.net> wrote:
> Juri Linkov wrote:
>
>> Can we return the to the initial design with a color like say
>> "RosyBrown4"?
>>
>
> Reminds me, I was going to nitpick that one of Lennart's favoured colors
> (#9C6969) was close to RosyBrown4 (#8B6969)

My favorites have changed a bit (or maybe I have changed). RosyBrown4
is unfortunately rather dull. It is possible to use more colored
colors which are easier to distinguish. My latest suggestions are to
use #797900 for strings and #9b6900 for variables.

But I am trying to find better tools to investigate this. If anyone
want to help me translating CIE.c from GIMP/GEGL to elisp, please mail
me.


> color-name-rgb-alist in tty-colors.el apparently contains a emacs-internal
> list of the well-known named colors (apparently leaving
> out a few that have platform specific interpretations according to the
> source comments), so:
>
> (defun colored-colorlist ()
>  (interactive)
>  (let ((buf (get-buffer-create "*color-list*")))
>    (with-current-buffer buf
>      (delete-region (point-min) (point-max))
>      (mapcar (lambda (l)
>                (insert (format "%-20s." (car l)))
>                (insert (propertize
>                         (format "%-20s.\n" (car l))
>                         'face (cons 'foreground-color  (car l)))))
>              color-name-rgb-alist))
>    (display-buffer buf)))


Is not that what list-colors-display does?

Re: Darkening font-lock colors

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > > Given that you are changing faces, how about changing the dark
  > > background, 8 color font-lock-comment-face to "yellow", then we can
  > > obsolete `font-lock-comment-delimiter-face'.
  > 
  > Why yellow?

It has good contrast with the black background and it is only used by
font-lock-variable-face on an 8 color dark background terminal.

Re: Darkening font-lock colors

[David De La Harpe Golden]

Lennart Borgman wrote:


> But I am trying to find better tools to investigate this. If anyone
> want to help me translating CIE.c from GIMP/GEGL to elisp, please mail
> me.

Randomly searching, I found this lgpl fortran 90 color coordinate 
conversion lib, FWIW, might or might not be easier to follow:
http://people.sc.fsu.edu/~burkardt/f_src/colors/colors.html

> Is not that what list-colors-display does?
> 
Er. yeah, basically. It's  time for bed...

Re: Darkening font-lock colors

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
> My favorites have changed a bit (or maybe I have changed). RosyBrown4
> is unfortunately rather dull. It is possible to use more colored
> colors which are easier to distinguish.

Being "easy to distinguish" is not the only goal.  There's also
"not driving the user insane" and "what my momma done used".

The thing is that every user seems to have different ideas what the
optimal goal is (thus stupid flame-wars anytime anyone suggests changing
face colors)...

-Miles

-- 
One of the lessons of history is that nothing is often a good thing to
do, and always a clever thing to say.  -- Will Durant

RE: Darkening font-lock colors

[Drew Adams]

Suggestion:

Once you all have fought it out and decided how the default faces should be
changed, and you've made the final changes, please add a simple table,
description, or instructions (e.g. in NEWS), to let users know what the defaults
were in Emacs 22.

That way, any user who wants to go back to one of those colors will know how to
customize the face to do so. Thx. Not a problem for those of us who use multiple
versions, but some users might not know how to find out what that color was that
they liked so much. ;-)

Re: Darkening font-lock colors

[Juri Linkov]

> Once you all have fought it out and decided how the default faces should be
> changed, and you've made the final changes, please add a simple table,
> description, or instructions (e.g. in NEWS), to let users know what the defaults
> were in Emacs 22.
>
> That way, any user who wants to go back to one of those colors will know how to
> customize the face to do so. Thx. Not a problem for those of us who use multiple
> versions, but some users might not know how to find out what that color was that
> they liked so much. ;-)

The right solution, of course, is to add a color theming support to Emacs
with an easy way to switch themes and to create the `emacs-23.1' color theme.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Darkening font-lock colors

[Juri Linkov]

>   > > Given that you are changing faces, how about changing the dark
>   > > background, 8 color font-lock-comment-face to "yellow", then we can
>   > > obsolete `font-lock-comment-delimiter-face'.
>   >
>   > Why yellow?
>
> It has good contrast with the black background and it is only used by
> font-lock-variable-face on an 8 color dark background terminal.

Then yellow would be good for font-lock-comment-face, but I think
font-lock-comment-delimiter should stay in red.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Darkening font-lock colors

[Daniel Clemente]

El dl, ago 03 2009 a les 11:54, Juri Linkov va escriure:
>
> The right solution, of course, is to add a color theming support to Emacs
> with an easy way to switch themes and to create the `emacs-23.1' color theme.

  Maybe some basic styles should be provided, like „black on white (default)“ and „white on black“.
  Changing themes is a feature offered by many editors. It is strange not to find this in a GNU Emacs menu option.

  Integrating color-theme.el [1] can be very useful since it is a commonly installed package (look for Emacs screenshots and you won't see many default themes).

[1] http://www.emacswiki.org/emacs/ColorTheme

Re: Darkening font-lock colors

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > >   > > Given that you are changing faces, how about changing the dark
  > >   > > background, 8 color font-lock-comment-face to "yellow", then we can
  > >   > > obsolete `font-lock-comment-delimiter-face'.
  > >   >
  > >   > Why yellow?
  > >
  > > It has good contrast with the black background and it is only used by
  > > font-lock-variable-face on an 8 color dark background terminal.
  > 
  > Then yellow would be good for font-lock-comment-face, but I think
  > font-lock-comment-delimiter should stay in red.

Why?  font-lock-comment-delimiter is a hack.  
And an unnecessary complication.
It was only introduced because the red foreground used on an 8 color
dark background terminal was not readable.
font-lock-comment-delimiter it is currently only used for 8 color dark
background terminals.

The problem is that this is confusing for users: we got many bug reports
about syntax coloring not working because the users saw the body of the
comments not being syntax highlighted.  Distributions (Debian, Ubuntu
and probably others too) patched this out by using red for
font-lock-comment-face, effectively defeating the purpose of why
font-lock-comment-delimiter was introduced.

So I am proposing to simplify this whole thing by removing the reason
for font-lock-comment-delimiter to exist: use a readable yellow
foreground on 8 color dark background terminals.

RE: Darkening font-lock colors

[Drew Adams]

> > Once you all have fought it out and decided how the default 
> > faces should be changed, and you've made the final changes,
> > please add a simple table, description, or instructions
> > (e.g. in NEWS), to let users know what the defaults
> > were in Emacs 22.
> >
> > That way, any user who wants to go back to one of those 
> > colors will know how to customize the face to do so. Thx.
> > Not a problem for those of us who use multiple
> > versions, but some users might not know how to find out 
> > what that color was that they liked so much. ;-)
> 
> The right solution, of course, is to add a color theming 
> support to Emacs with an easy way to switch themes and to
> create the `emacs-23.1' color theme.

No, that's orthogonal - might be good or bad, but not the solution for this.

A user might well like the new colors in general but prefer one of the old
colors. But what was it? This is not about choosing between two themes (neither
of which might be appropriate).

Please let's not complicate the issue (now it becomes a discussion about
including theme code...). Just publish the old colors and the corresponding new
ones. If you do that, it really doesn't matter much what colors you use.

It is important to list changes in any default values/behavior at each release,
stating clearly what the old was and the new is in each case. That is normal
behavior.

Re: Darkening font-lock colors

[joakim]

Juri Linkov <juri@jurta.org> writes:

>> Once you all have fought it out and decided how the default faces should be
>> changed, and you've made the final changes, please add a simple table,
>> description, or instructions (e.g. in NEWS), to let users know what the defaults
>> were in Emacs 22.
>>
>> That way, any user who wants to go back to one of those colors will know how to
>> customize the face to do so. Thx. Not a problem for those of us who use multiple
>> versions, but some users might not know how to find out what that color was that
>> they liked so much. ;-)
>
> The right solution, of course, is to add a color theming support to Emacs
> with an easy way to switch themes and to create the `emacs-23.1' color theme.

That would indeed be splendid.

Can't we start merging the existing color-theme package, and iron out
whatever wrinkles it has?

-- 
Joakim Verona

Re: Darkening font-lock colors

[Stephen Eilert]

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

Is there anything preventing color-theme.el from being included in Emacs?
That way themes could be provided to better account for particular user
tastes.


--Stephen

programmer, n:
       A red eyed, mumbling mammal capable of conversing with inanimate
monsters.


On Mon, Aug 3, 2009 at 9:34 AM, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Juri Linkov <juri@jurta.org> writes:
>
>   > >   > > Given that you are changing faces, how about changing the dark
>  > >   > > background, 8 color font-lock-comment-face to "yellow", then we
> can
>  > >   > > obsolete `font-lock-comment-delimiter-face'.
>  > >   >
>  > >   > Why yellow?
>  > >
>  > > It has good contrast with the black background and it is only used by
>  > > font-lock-variable-face on an 8 color dark background terminal.
>  >
>  > Then yellow would be good for font-lock-comment-face, but I think
>  > font-lock-comment-delimiter should stay in red.
>
> Why?  font-lock-comment-delimiter is a hack.
> And an unnecessary complication.
> It was only introduced because the red foreground used on an 8 color
> dark background terminal was not readable.
> font-lock-comment-delimiter it is currently only used for 8 color dark
> background terminals.
>
> The problem is that this is confusing for users: we got many bug reports
> about syntax coloring not working because the users saw the body of the
> comments not being syntax highlighted.  Distributions (Debian, Ubuntu
> and probably others too) patched this out by using red for
> font-lock-comment-face, effectively defeating the purpose of why
> font-lock-comment-delimiter was introduced.
>
> So I am proposing to simplify this whole thing by removing the reason
> for font-lock-comment-delimiter to exist: use a readable yellow
> foreground on 8 color dark background terminals.
>
>
>

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

Re: Darkening font-lock colors

[Lennart Borgman]

On Mon, Aug 3, 2009 at 7:13 AM, Miles Bader<miles@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>> My favorites have changed a bit (or maybe I have changed). RosyBrown4
>> is unfortunately rather dull. It is possible to use more colored
>> colors which are easier to distinguish.
>
> Being "easy to distinguish" is not the only goal.  There's also
> "not driving the user insane" and "what my momma done used".

Going into a state of "insanity" might be a good chance for a change...


> The thing is that every user seems to have different ideas what the
> optimal goal is (thus stupid flame-wars anytime anyone suggests changing
> face colors)...

Yes, but I think most people will agree that default colors that are
good from an accessibility vewpoint should be favoured. And that also
estetics and usability are very important.

I have found it surpisingly hard to find colors that have both good
luminance color contrast (accessibility, suggested by WCAG) and are
distinguishable and pleasant (usability). And then I did not even
consider color blindness (which I think should go on top of this).

As I have told before one reason that this problem is hard to solve is
that when you raise the contrast requirement you get fewer colors to
play with. In my little tool (which you can currently find on
EmacsWiki) I have a tweaked version of list-colors-display (called
flct-list-colors-display) where I sort colors according to contrast
and hue. Looking at this color list display makes it very apparent how
few distinguishable colors there are too choose from.

It also makes another thing apparent. The colors that have good
contrast are mostly rather hard while the soft and nice colors have
less contrast. (Actually I wonder if this is one reason for some
people prefer dark backgrounds. Then they can have more friendly
colors in foreground. But personally I found it a bit harder to read
on dark backgrounds.) Using more friendly colors probably help getting
you into a good mood and makes you more creative - but they must of
course be readable.

Now how can we tackle this dilemma?

I suggest we have one resource that we have not used: The background color.

Using different backgrounds for different parts is a powerful tool
that makes those parts stand out (so it should be used cautiously).
This is of course why it is used for selection (with a color that
stands out). It is also a common tool in web page design to help users
understand the structure of the page (and also too fool them ...). So
on a computer screen users are aware of this kind of use of background
colors.

The luminance color contrast when using a slightly colored background
(in the case of light backgrounds of course) is still very good. This
is probably a surprise for many people. There are some no-no:s like
using the opposite colors from the color wheel for foreground and
backgrounds that of course should be avoided. But apart from that I
think there are no accessibility problems. From a usability view it is
in my opinion important that the backgrounds are only slightly colored
since otherwise it is distracting.

So I would suggest using friendly slightly colored backgrounds for
different parts. When it comes to syntactic font locking there are
three parts where I can see it can be used: Comments, doc strings and
normal strings. Those parts should in my opinion stand out a little
bit since all the text in a such part belongs together. This means
that the background color does not distract the logic view of the
buffer, but enhances it.

I have changed my color suggestions to reflect this in

    http://www.emacswiki.org/emacs/font-lock-color-test.el


BTW: I have long used colored backgrounds in MuMaMo/nXhtml. From the
beginning I heard some protests, but I have heard none for long time.
I saw one user complained recently (though not directly to me) but I
think this was more due to the low contrast in the current default
font lock faces.

Re: Darkening font-lock colors

[David De La Harpe Golden]

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

joakim@verona.se wrote:

> That would indeed be splendid.
> 
> Can't we start merging the existing color-theme package, and iron out
> whatever wrinkles it has?
> 

Hmm. I've never really looked at it before. I think "color-theme" might 
be a bit of a misnomer as it's apparently quite capable of theming the 
other face  properties - it's really "face-theme"  e.g. the bundled 
example munges bold/italic.  Not saying that's  a bad thing, but the 
code is therefore a lot more complex than a purely color oriented system.

Related to recent discussions about color name parsing - how about 
being able to say "@blah:comment" in a color string (e.g. face 
foreground property), that indirects through an alist in 
colorscheme-blah, looking up "comment"? (or whatever, that particular
scheme was just simple to implement)

Quick proof of concept patch attached. Potentially with a small can of 
worms regarding display and background dependence, but frame is also 
passed through to colorscheme-lookup, the simple colorscheme-lookup 
function included in the patch just doesn't do anything much with it.
Less powerful overall than color-theme? Undoubtedly. But may in fact be 
complementary (themes could set face colors to 
@themes-colorscheme-name:key and/or redefine relevant colorscheme-blah 
alists), and could in principle also be used for colors other than face 
colors.

OTOH, may very well be needlessly complicating things.


















[-- Attachment #2: colorscheme_r1.diff --]
[-- Type: text/x-patch, Size: 13188 bytes --]

Index: lisp/faces.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/faces.el,v
retrieving revision 1.443
diff -U 8 -r1.443 faces.el
--- lisp/faces.el	27 Jun 2009 20:44:07 -0000	1.443
+++ lisp/faces.el	3 Aug 2009 20:35:18 -0000
@@ -1626,18 +1626,18 @@
 (defun color-defined-p (color &optional frame)
   "Return non-nil if color COLOR is supported on frame FRAME.
 If FRAME is omitted or nil, use the selected frame.
 If COLOR is the symbol `unspecified' or one of the strings
 \"unspecified-fg\" or \"unspecified-bg\", the value is nil."
   (if (member color '(unspecified "unspecified-bg" "unspecified-fg"))
       nil
     (if (member (framep (or frame (selected-frame))) '(x w32 ns))
-	(xw-color-defined-p color frame)
-      (numberp (tty-color-translate color frame)))))
+	(xw-color-defined-p (or (colorscheme-lookup color frame) color) frame)
+      (numberp (tty-color-translate (or (colorscheme-lookup color frame) color) frame)))))
 (defalias 'x-color-defined-p 'color-defined-p)
 
 (declare-function xw-color-values "xfns.c" (color &optional frame))
 
 (defun color-values (color &optional frame)
   "Return a description of the color named COLOR on frame FRAME.
 The value is a list of integer RGB values--(RED GREEN BLUE).
 These values appear to range from 0 to 65280 or 65535, depending
@@ -2678,12 +2678,38 @@
 
 (defun x-make-font-bold-italic (font)
   "Given an X font specification, make a bold and italic version of it.
 If that can't be done, return nil."
   (and (setq font (internal-frob-font-weight font "bold"))
        (internal-frob-font-slant font "i")))
 (make-obsolete 'x-make-font-bold-italic 'make-face-bold-italic "21.1")
 
+
+(defun colorscheme-lookup (colorspec frame)
+  "Resolve '@table:name' to a named color via an alist in colorscheme-table
+   Used to allow indirect color specifications in face definitions."
+  ;; e.g.
+  ;; (setq colorscheme-lennart1
+  ;;	'(("builtin"  "Orchid4")
+  ;;	  ("preprocessor"  "DeepPink3")
+  ;;	  ("warning"  "red2")
+  ;;	  ("comment"  "Firebrick")
+  ;;	  ("constant"  "#00765b")
+  ;;	  ("doc"  "gold4")
+  ;;	  ("string"  "#797900")
+  ;;	  ("variable-name"  "#9b6900")))
+  ;;
+  ;; (colorscheme-lookup "@lennart1:doc" (selected-frame))
+  ;; => "gold4"
+  (save-match-data
+    (when (string-match "^@\\(.+\\):\\(.+\\)$" colorspec)
+      (let* ((table (match-string 1 colorspec))
+	     (key (match-string 2 colorspec))
+	     (tablesym (intern (concat "colorscheme-" table))))
+	(when (and (boundp tablesym) key)
+	  (cadr (assoc key (symbol-value tablesym))))))))
+
+
 (provide 'faces)
 
 ;; arch-tag: 19a4759f-2963-445f-b004-425b9aadd7d6
 ;;; faces.el ends here
Index: lisp/font-lock.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/font-lock.el,v
retrieving revision 1.351
diff -U 8 -r1.351 font-lock.el
--- lisp/font-lock.el	2 Aug 2009 14:20:10 -0000	1.351
+++ lisp/font-lock.el	3 Aug 2009 20:35:18 -0000
@@ -1830,25 +1830,35 @@
 	(font-lock-remove-keywords nil removed-keywords))
       ;; Now compile the keywords.
       (unless (eq (car font-lock-keywords) t)
 	(setq font-lock-keywords
               (font-lock-compile-keywords font-lock-keywords))))))
 \f
 ;;; Color etc. support.
 
+(defvar colorscheme-fldefault
+  '(("builtin"  "Orchid4")
+    ("preprocessor"  "DeepPink3")  ; FIXME: not adjusted below
+    ("warning"  "red2")
+    ("comment"  "Firebrick")
+    ("constant"  "#00765b")
+    ("doc"  "gold4")               ; FIXME: not adjusted below
+    ("string"  "#797900")
+    ("variable-name"  "#9b6900")))
+
 ;; Note that `defface' will not overwrite any faces declared above via
 ;; `custom-declare-face'.
 (defface font-lock-comment-face
   '((((class grayscale) (background light))
      (:foreground "DimGray" :weight bold :slant italic))
     (((class grayscale) (background dark))
      (:foreground "LightGray" :weight bold :slant italic))
     (((class color) (min-colors 88) (background light))
-     (:foreground "Firebrick"))
+     (:foreground "@fldefault:comment"))
     (((class color) (min-colors 88) (background dark))
      (:foreground "chocolate1"))
     (((class color) (min-colors 16) (background light))
      (:foreground "red"))
     (((class color) (min-colors 16) (background dark))
      (:foreground "red1"))
     (((class color) (min-colors 8) (background light))
      (:foreground "red"))
@@ -1867,17 +1877,17 @@
     (((class color) (min-colors 8) (background dark))
      :foreground "red1"))
   "Font Lock mode face used to highlight comment delimiters."
   :group 'font-lock-faces)
 
 (defface font-lock-string-face
   '((((class grayscale) (background light)) (:foreground "DimGray" :slant italic))
     (((class grayscale) (background dark)) (:foreground "LightGray" :slant italic))
-    (((class color) (min-colors 88) (background light)) (:foreground "VioletRed4"))
+    (((class color) (min-colors 88) (background light)) (:foreground "@fldefault:string"))
     (((class color) (min-colors 88) (background dark)) (:foreground "LightSalmon"))
     (((class color) (min-colors 16) (background light)) (:foreground "RosyBrown"))
     (((class color) (min-colors 16) (background dark)) (:foreground "LightSalmon"))
     (((class color) (min-colors 8)) (:foreground "green"))
     (t (:slant italic)))
   "Font Lock mode face used to highlight strings."
   :group 'font-lock-faces)
 
@@ -1896,17 +1906,17 @@
     (((class color) (min-colors 8)) (:foreground "cyan" :weight bold))
     (t (:weight bold)))
   "Font Lock mode face used to highlight keywords."
   :group 'font-lock-faces)
 
 (defface font-lock-builtin-face
   '((((class grayscale) (background light)) (:foreground "LightGray" :weight bold))
     (((class grayscale) (background dark)) (:foreground "DimGray" :weight bold))
-    (((class color) (min-colors 88) (background light)) (:foreground "MediumOrchid4"))
+    (((class color) (min-colors 88) (background light)) (:foreground "@fldefault:builtin"))
     (((class color) (min-colors 88) (background dark)) (:foreground "LightSteelBlue"))
     (((class color) (min-colors 16) (background light)) (:foreground "Orchid"))
     (((class color) (min-colors 16) (background dark)) (:foreground "LightSteelBlue"))
     (((class color) (min-colors 8)) (:foreground "blue" :weight bold))
     (t (:weight bold)))
   "Font Lock mode face used to highlight builtins."
   :group 'font-lock-faces)
 
@@ -1920,17 +1930,17 @@
   "Font Lock mode face used to highlight function names."
   :group 'font-lock-faces)
 
 (defface font-lock-variable-name-face
   '((((class grayscale) (background light))
      (:foreground "Gray90" :weight bold :slant italic))
     (((class grayscale) (background dark))
      (:foreground "DimGray" :weight bold :slant italic))
-    (((class color) (min-colors 88) (background light)) (:foreground "sienna"))
+    (((class color) (min-colors 88) (background light)) (:foreground "@fldefault:variable-name"))
     (((class color) (min-colors 88) (background dark)) (:foreground "LightGoldenrod"))
     (((class color) (min-colors 16) (background light)) (:foreground "DarkGoldenrod"))
     (((class color) (min-colors 16) (background dark)) (:foreground "LightGoldenrod"))
     (((class color) (min-colors 8)) (:foreground "yellow" :weight light))
     (t (:weight bold :slant italic)))
   "Font Lock mode face used to highlight variable names."
   :group 'font-lock-faces)
 
@@ -1946,27 +1956,27 @@
   "Font Lock mode face used to highlight type and classes."
   :group 'font-lock-faces)
 
 (defface font-lock-constant-face
   '((((class grayscale) (background light))
      (:foreground "LightGray" :weight bold :underline t))
     (((class grayscale) (background dark))
      (:foreground "Gray50" :weight bold :underline t))
-    (((class color) (min-colors 88) (background light)) (:foreground "dark cyan"))
+    (((class color) (min-colors 88) (background light)) (:foreground "@fldefault:constant"))
     (((class color) (min-colors 88) (background dark)) (:foreground "Aquamarine"))
     (((class color) (min-colors 16) (background light)) (:foreground "CadetBlue"))
     (((class color) (min-colors 16) (background dark)) (:foreground "Aquamarine"))
     (((class color) (min-colors 8)) (:foreground "magenta"))
     (t (:weight bold :underline t)))
   "Font Lock mode face used to highlight constants and labels."
   :group 'font-lock-faces)
 
 (defface font-lock-warning-face
-  '((((class color) (min-colors 88) (background light)) (:foreground "Red1" :weight bold))
+  '((((class color) (min-colors 88) (background light)) (:foreground "@fldefault:warning" :weight bold))
     (((class color) (min-colors 88) (background dark)) (:foreground "Pink" :weight bold))
     (((class color) (min-colors 16) (background light)) (:foreground "Red1" :weight bold))
     (((class color) (min-colors 16) (background dark)) (:foreground "Pink" :weight bold))
     (((class color) (min-colors 8)) (:foreground "red"))
     (t (:inverse-video t :weight bold)))
   "Font Lock mode face used to highlight warnings."
   :group 'font-lock-faces)
 
Index: src/xfaces.c
===================================================================
RCS file: /sources/emacs/emacs/src/xfaces.c,v
retrieving revision 1.438
diff -U 8 -r1.438 xfaces.c
--- src/xfaces.c	27 Jul 2009 04:19:03 -0000	1.438
+++ src/xfaces.c	3 Aug 2009 20:35:18 -0000
@@ -448,16 +448,20 @@
 
 static int next_lface_id;
 
 /* A vector mapping Lisp face Id's to face names.  */
 
 static Lisp_Object *lface_id_to_name;
 static int lface_id_to_name_size;
 
+/* Colorscheme lookup function (defined in faces.el). */
+
+Lisp_Object Qcolorscheme_lookup;
+
 /* TTY color-related functions (defined in tty-colors.el).  */
 
 Lisp_Object Qtty_color_desc, Qtty_color_by_index, Qtty_color_standard_values;
 
 /* The name of the function used to compute colors on TTYs.  */
 
 Lisp_Object Qtty_color_alist;
 
@@ -1246,29 +1250,48 @@
 
 int
 defined_color (f, color_name, color_def, alloc)
      struct frame *f;
      char *color_name;
      XColor *color_def;
      int alloc;
 {
+  char *resolved_color_name;
+  resolved_color_name = color_name;
+
+  /* indirect through colorscheme-lookup function if color_name starts with @ */
+  if (color_name[0] == '@') {
+    if (!NILP (Ffboundp (Qcolorscheme_lookup)))
+      {
+	Lisp_Object frame;
+	Lisp_Object resolved_color;
+
+	XSETFRAME (frame, f);
+	resolved_color = call2 (Qcolorscheme_lookup, build_string(color_name), frame);
+	if (STRINGP (resolved_color))
+	  {
+	    resolved_color_name = SDATA(resolved_color);
+	  }
+      }
+  }
+
   if (!FRAME_WINDOW_P (f))
-    return tty_defined_color (f, color_name, color_def, alloc);
+    return tty_defined_color (f, resolved_color_name, color_def, alloc);
 #ifdef HAVE_X_WINDOWS
   else if (FRAME_X_P (f))
-    return x_defined_color (f, color_name, color_def, alloc);
+    return x_defined_color (f, resolved_color_name, color_def, alloc);
 #endif
 #ifdef WINDOWSNT
   else if (FRAME_W32_P (f))
-    return w32_defined_color (f, color_name, color_def, alloc);
+    return w32_defined_color (f, resolved_color_name, color_def, alloc);
 #endif
 #ifdef HAVE_NS
   else if (FRAME_NS_P (f))
-    return ns_defined_color (f, color_name, color_def, alloc, 1);
+    return ns_defined_color (f, resolved_color_name, color_def, alloc, 1);
 #endif
   else
     abort ();
 }
 
 
 /* Given the index IDX of a tty color on frame F, return its name, a
    Lisp string.  */
@@ -6875,16 +6898,20 @@
   Qborder = intern ("border");
   staticpro (&Qborder);
   Qmouse = intern ("mouse");
   staticpro (&Qmouse);
   Qmode_line_inactive = intern ("mode-line-inactive");
   staticpro (&Qmode_line_inactive);
   Qvertical_border = intern ("vertical-border");
   staticpro (&Qvertical_border);
+
+  Qcolorscheme_lookup = intern ("colorscheme-lookup");
+  staticpro (&Qcolorscheme_lookup);
+
   Qtty_color_desc = intern ("tty-color-desc");
   staticpro (&Qtty_color_desc);
   Qtty_color_standard_values = intern ("tty-color-standard-values");
   staticpro (&Qtty_color_standard_values);
   Qtty_color_by_index = intern ("tty-color-by-index");
   staticpro (&Qtty_color_by_index);
   Qtty_color_alist = intern ("tty-color-alist");
   staticpro (&Qtty_color_alist);
Index: src/xfns.c
===================================================================
RCS file: /sources/emacs/emacs/src/xfns.c,v
retrieving revision 1.742
diff -U 8 -r1.742 xfns.c
--- src/xfns.c	10 Jul 2009 17:07:38 -0000	1.742
+++ src/xfns.c	3 Aug 2009 20:35:18 -0000
@@ -766,17 +766,19 @@
 #endif
 
   /* Return MONO_COLOR for monochrome frames.  */
   if (FRAME_X_DISPLAY_INFO (f)->n_planes == 1)
     return mono_color;
 
   /* x_defined_color is responsible for coping with failures
      by looking for a near-miss.  */
-  if (x_defined_color (f, SDATA (color_name), &cdef, 1))
+  /* call defined_color which will call x_defined_color for us
+     to allow @indirect color resolution to take place */
+  if (defined_color (f, SDATA (color_name), &cdef, 1))
     return cdef.pixel;
 
   signal_error ("Undefined color", color_name);
 }
 
 
 \f
 /* Change the `wait-for-wm' frame parameter of frame F.  OLD_VALUE is

Re: Darkening font-lock colors

[Stefan Monnier]

> So I am proposing to simplify this whole thing by removing the reason
> for font-lock-comment-delimiter to exist: use a readable yellow
> foreground on 8 color dark background terminals.

I don't have strong opinions about faces, and don't have time to try
them out to make sure they work OK, but if we can find a setting that
allows us to get rid of font-lock-comment-delimiter, I'd be in favor
of it.


        Stefan

RE: Darkening font-lock colors

[Drew Adams]

> I have found it surpisingly hard to find colors that have both good
> luminance color contrast (accessibility, suggested by WCAG) and are
> distinguishable and pleasant (usability). And then I did not even
> consider color blindness (which I think should go on top of this).

1. The solution to that dilemna of contrasting needs is not a compromise. It is
to offer 3 or more general settings. Themes, if you like, but it need not be as
full-blown as themes. Even just 3 choices for a small set of default faces would
be a good first step.


2. FWIW, I am against having both foregrounds and backgrounds defined for faces
such as font-lock faces, that is, for the default values. Distracting & ugly.
Also, they look odd when over trailing whitespace.

Such faces can be OK for things like headings and directories in Dired.
Otherwise, they are not very helpful, IMO.

(Faces that are background only (no foreground) are good for highlighting,
obviously.)

The main thing is that faces intended for text, especially large chunks of text,
should avoid using a background.

Just one opinion.

Re: Darkening font-lock colors

[Lennart Borgman]

On Tue, Aug 4, 2009 at 12:40 AM, Drew Adams<drew.adams@oracle.com> wrote:
>> I have found it surpisingly hard to find colors that have both good
>> luminance color contrast (accessibility, suggested by WCAG) and are
>> distinguishable and pleasant (usability). And then I did not even
>> consider color blindness (which I think should go on top of this).
>
> 1. The solution to that dilemna of contrasting needs is not a compromise. It is
> to offer 3 or more general settings. Themes, if you like, but it need not be as
> full-blown as themes. Even just 3 choices for a small set of default faces would
> be a good first step.

Maybe, but a good default is also good to have.

I think jumping into themes right away would just prevent good defaults.


> 2. FWIW, I am against having both foregrounds and backgrounds defined for faces
> such as font-lock faces, that is, for the default values. Distracting & ugly.

I think it is helpful that makes for exampel comments stand out a bit
as I said because it holds those pieces of text together and a bit
apart from other text. This is the same use they often have in a web
page.

However the color difference must be small otherwise the text with a
background color will perhaps stand out to much. I think there is a
balance between standing out too much or too little.

In what way do you think it distracting?


> Also, they look odd when over trailing whitespace.

I see no visual problem there. Can you tell me what you see?

Re: Darkening font-lock colors

[Dan Nicolaescu]

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

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

  > > So I am proposing to simplify this whole thing by removing the reason
  > > for font-lock-comment-delimiter to exist: use a readable yellow
  > > foreground on 8 color dark background terminals.
  > 
  > I don't have strong opinions about faces, and don't have time to try
  > them out to make sure they work OK, but if we can find a setting that
  > allows us to get rid of font-lock-comment-delimiter, I'd be in favor
  > of it.

This is the first step to accomplish that (use yellow for the problem
case and just make font-lock-comment-delimiter be identical to
font-lock-comment-face):

--- font-lock.el.~1.351.~       2009-08-02 10:53:38.000000000 -0700
+++ font-lock.el                2009-08-03 15:48:35.000000000 -0700
@@ -1853,19 +1853,13 @@ Sets various variables using `font-lock-
     (((class color) (min-colors 8) (background light))
      (:foreground "red"))
     (((class color) (min-colors 8) (background dark))
-     )
+     (:foreground "yellow"))
     (t (:weight bold :slant italic)))
   "Font Lock mode face used to highlight comments."
   :group 'font-lock-faces)
 
 (defface font-lock-comment-delimiter-face
-  '((default :inherit font-lock-comment-face)
-    (((class grayscale)))
-    (((class color) (min-colors 16)))
-    (((class color) (min-colors 8) (background light))
-     :foreground "red")
-    (((class color) (min-colors 8) (background dark))
-     :foreground "red1"))
+  '((default :inherit font-lock-comment-face))
   "Font Lock mode face used to highlight comment delimiters."
   :group 'font-lock-faces)


Here's how it looks on a black background terminal:


[-- Attachment #2: f.jpg --]
[-- Type: image/jpeg, Size: 45764 bytes --]

[-- Attachment #3: Type: text/plain, Size: 288 bytes --]


it looks good too on a Linux console (now idea how to get a screen dump
there, but it's easy to do M-x list-colors-display to see how yellow on
back looks like).

Is this first step OK?
Obviously there's some more search&replace work + removing some code
needed to complete the removal.

Re: Darkening font-lock colors

[Juri Linkov]

> But I am trying to find better tools to investigate this. If anyone
> want to help me translating CIE.c from GIMP/GEGL to elisp, please mail
> me.

The formulas for CIE conversions are not too complex.
Maybe this information will be of some help to you:
http://lists.gnu.org/archive/html/emacs-devel/2000-11/msg00118.html

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Darkening font-lock colors

[Juri Linkov]

> Distributions (Debian, Ubuntu and probably others too) patched this
> out by using red for font-lock-comment-face, effectively defeating the
> purpose of why font-lock-comment-delimiter was introduced.

Distributions use red for font-lock-comment-face because it is
associated with comments, but yellow is something unrelated.

Actually I tried on a Linux console and xterm and see the dark orange
color instead of yellow.  Orange is closer to red, so if everyone sees
the same color similar to red then there may be no problem with this change.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Darkening font-lock colors

[Juri Linkov]

> Just publish the old colors and the corresponding new
> ones. If you do that, it really doesn't matter much what colors you use.
>
> It is important to list changes in any default values/behavior at each release,
> stating clearly what the old was and the new is in each case. That is normal
> behavior.

What is shorter to put in NEWS: complete definitions of old
and new faces (ca 50 lines) or simply a text like "you can
switch back to `color-theme-emacs-23.1"?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Darkening font-lock colors

[Lennart Borgman]

On Tue, Aug 4, 2009 at 1:27 AM, Juri Linkov<juri@jurta.org> wrote:
>> But I am trying to find better tools to investigate this. If anyone
>> want to help me translating CIE.c from GIMP/GEGL to elisp, please mail
>> me.
>
> The formulas for CIE conversions are not too complex.
> Maybe this information will be of some help to you:
> http://lists.gnu.org/archive/html/emacs-devel/2000-11/msg00118.html

Thanks, those looks accurate, but ... - did you notice that item 5.3
is missing? That is the part I am most wondering about, the constants.
However I think I got the needed information from a GIMP developer.

But it is a bit tedious to implement. Are there any good descriptions
of vector/matrix handling in elisp? Like everyone else I am fond of
reinventing the wheel, but not every time.

RE: Darkening font-lock colors

[Drew Adams]

> > Just publish the old colors and the corresponding new
> > ones. If you do that, it really doesn't matter much what 
> > colors you use.
> >
> > It is important to list changes in any default 
> > values/behavior at each release, stating clearly what
> > the old was and the new is in each case. That is normal
> > behavior.
> 
> What is shorter to put in NEWS: complete definitions of old
> and new faces (ca 50 lines) or simply a text like "you can
> switch back to `color-theme-emacs-23.1"?

1. Did you miss this point:

>> A user might well like the new colors in general but prefer 
>> one of the old colors. But what was it? This is not about
>> choosing between two themes (neither of which might be appropriate).

When you change themes, you get the whole package, lock, stock, and barrel.
Knowing what a given face was that you liked lets you restore just that face.

2. The criterion should be helping users the most, not minimizing the number of
bytes in NEWS. And even if it takes an extra 1000 bytes, no big deal.

3. Listing changed default settings is normal behavior for any released
software. It is the least we owe to users.

RE: Darkening font-lock colors

[Drew Adams]

> Maybe, but a good default is also good to have.

Yes, a _good_ default. My point was that if you start trading off between
accessibility, usability, and who-knows-what-else, the result might not be so
good.

I certainly agree that themes are not the place to start, and that we should try
for good defaults. You, not I, pointed out the conflicts between different sets
of criteria. My point was that you will respect none of those sets if you try a
half-way compromise (probably).

> I think jumping into themes right away would just prevent 
> good defaults.

Dunno if it would prevent anything, but I agree that good defaults come first.
 
> > 2. FWIW, I am against having both foregrounds and 
> backgrounds defined for faces
> > such as font-lock faces, that is, for the default values. 
> Distracting & ugly.
> 
> I think it is helpful that makes for exampel comments stand out a bit
> as I said because it holds those pieces of text together and a bit
> apart from other text. This is the same use they often have in a web
> page.

We will agree to disagree. One person's stands-out-nicely is another person's
annoying distraction.

> However the color difference must be small otherwise the text with a
> background color will perhaps stand out to much. I think there is a
> balance between standing out too much or too little.
> 
> In what way do you think it distracting?

See above.

> > Also, they look odd when over trailing whitespace.
> 
> I see no visual problem there. Can you tell me what you see?

It won't convince you, but even without trailing whitespace, I find large chunks
of faces with fg and bg to look odd against the page background. It's like
putting boxes around each line of text. If it looks good to you, fine. Just one
opinion.

A face that has the same background (i.e. no background) as the page looks like
text on the page. A face that has no foreground looks like highlighting. Both
are good.

A face that has a foreground and a background that is different from the page
looks like a boxed heading. And a chunk of such text doesn't look like a
rectangular text box. It looks like a set of Lego blocks, with varying right
edges due to different line lengths.

FWIW. 

Re: Darkening font-lock colors

[Lennart Borgman]

On Tue, Aug 4, 2009 at 1:54 AM, Drew Adams<drew.adams@oracle.com> wrote:
>> Maybe, but a good default is also good to have.
>
> Yes, a _good_ default. My point was that if you start trading off between
> accessibility, usability, and who-knows-what-else, the result might not be so
> good.

I have not talked about trading off. I have said the reverse that we
do not have to do that. We can meet the requirement for accessibility
(as specified by WCAG) and still have room for usability changes.


>> > 2. FWIW, I am against having both foregrounds and
>> I think it is helpful that makes for exampel comments stand out a bit
>> as I said because it holds those pieces of text together and a bit
>> apart from other text. This is the same use they often have in a web
>> page.
>
> We will agree to disagree. One person's stands-out-nicely is another person's
> annoying distraction.
>
>> However the color difference must be small otherwise the text with a
>> background color will perhaps stand out to much. I think there is a
>> balance between standing out too much or too little.
>>
>> In what way do you think it distracting?
>
> See above.

Yes, but if you tell me more I can maybe suggest something better.


>> > Also, they look odd when over trailing whitespace.
>>
>> I see no visual problem there. Can you tell me what you see?
>
> It won't convince you, but even without trailing whitespace, I find large chunks
> of faces with fg and bg to look odd against the page background. It's like
> putting boxes around each line of text. If it looks good to you, fine. Just one
> opinion.
>
> A face that has the same background (i.e. no background) as the page looks like
> text on the page. A face that has no foreground looks like highlighting. Both
> are good.
>
> A face that has a foreground and a background that is different from the page
> looks like a boxed heading. And a chunk of such text doesn't look like a
> rectangular text box. It looks like a set of Lego blocks, with varying right
> edges due to different line lengths.

It sounds like it looks very different on your display. Could you
perhaps show an image?

RE: Darkening font-lock colors

[Drew Adams]

> I have not talked about trading off. I have said the reverse that we
> do not have to do that. We can meet the requirement for accessibility
> (as specified by WCAG) and still have room for usability changes.

OK, good.

> Yes, but if you tell me more I can maybe suggest something better.

Same thing you said: maybe it's too much. I don't have more to say about it.

> It sounds like it looks very different on your display. Could you
> perhaps show an image?

No, it's the same. Nevermind about it. Just record one opinion not in favor. See
what others think.

As I said already, I don't really care what the default faces are. Just let
users know what they were before, in case they liked one of the old colors and
want to customize to it.

Re: Darkening font-lock colors

[Romain Francoise]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> This is the first step to accomplish that (use yellow for the problem
> case and just make font-lock-comment-delimiter be identical to
> font-lock-comment-face): [...]

I've tried it and I don't like it very much... Compared to my usual
color scheme where comments are in red (Debian-patched Emacs), it
makes it harder to visually separate comments from code in certain
modes (e.g. Makefiles) because `font-lock-variable-name-face' is
also yellow.

Re: Darkening font-lock colors

[Lennart Borgman]

On Tue, Aug 4, 2009 at 10:27 AM, Romain Francoise<romain@orebokech.com> wrote:
> Dan Nicolaescu <dann@ics.uci.edu> writes:
>
>> This is the first step to accomplish that (use yellow for the problem
>> case and just make font-lock-comment-delimiter be identical to
>> font-lock-comment-face): [...]
>
> I've tried it and I don't like it very much... Compared to my usual
> color scheme where comments are in red (Debian-patched Emacs), it
> makes it harder to visually separate comments from code in certain
> modes (e.g. Makefiles) because `font-lock-variable-name-face' is
> also yellow.

Is that default? (For dark backgrounds I guess ... ;-)

Re: Darkening font-lock colors

[Johan Bockgård]

Lennart Borgman <lennart.borgman@gmail.com> writes:

>> A face that has a foreground and a background that is different from
>> the page looks like a boxed heading. And a chunk of such text doesn't
>> look like a rectangular text box. It looks like a set of Lego blocks,
>> with varying right edges due to different line lengths.
>
> It sounds like it looks very different on your display. Could you
> perhaps show an image?

http://www.emacswiki.org/pics/static/bojohan-face-background.png.png

Re: Darkening font-lock colors

[Juri Linkov]

As proposed in http://lists.gnu.org/archive/html/emacs-devel/2005-01/msg00251.html
I implemented the color sorting option for `list-colors-display'.

Below is a short patch that adds a customizable variable
`list-colors-sort' with some useful sort orders to sort
by color name, RGB, HSV, and HVS distance to the specified color.
The default is unordered - the same order as now.

The HVS distance is the most useful sorting order.
For instance, for the source color "rosy brown"
(the former `font-lock-string-face' color) it shows
that a new color "VioletRed4" is far away from "rosy brown".
The closest colors for "rosy brown" on the HVS cylinder are:

  rosy brown
  RosyBrown3
  RosyBrown4
  RosyBrown2
  RosyBrown1
  light coral
  indian red
  IndianRed3
  IndianRed4
  IndianRed2
  IndianRed1
  brown
  brown3
  brown4
  brown2
  firebrick

The actual patch for color sorting is below:

Index: lisp/facemenu.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/facemenu.el,v
retrieving revision 1.108
diff -c -r1.108 facemenu.el
*** lisp/facemenu.el	18 Apr 2009 13:50:23 -0000	1.108
--- lisp/facemenu.el	4 Aug 2009 22:12:43 -0000
***************
*** 469,474 ****
--- 469,534 ----
  	nil
        col)))
  
+ (defun rgb-to-hsv (r g b)
+   "For R, G, B color components return a list of hue, saturation, value.
+ R, G, B input values should be in [0..65535] range.
+ Output values for hue are in [0..360] range.
+ Output values for saturation and value are in [0..1] range."
+   (let* ((r (/ r 65535.0))
+ 	 (g (/ g 65535.0))
+ 	 (b (/ b 65535.0))
+ 	 (max (max r g b))
+ 	 (min (min r g b))
+ 	 (h (cond ((= max min) 0)
+ 		  ((= max r) (mod (+ (* 60 (/ (- g b) (- max min))) 360) 360))
+ 		  ((= max g) (+ (* 60 (/ (- b r) (- max min))) 120))
+ 		  ((= max b) (+ (* 60 (/ (- r g) (- max min))) 240))))
+ 	 (s (cond ((= max 0) 0)
+ 		  (t (- 1 (/ min max)))))
+ 	 (v max))
+     (list h s v)))
+ 
+ (defcustom list-colors-sort nil
+   "Sort order for `list-colors-display'.
+ `nil' means unsorted (implementation-dependent order).
+ `name' sorts by color name.
+ `r-g-b' sorts by red, green, blue components.
+ `h-s-v' sorts by hue, saturation, value.
+ `hsv-dist' sorts by the HVS distance to the specified color."
+   :type '(choice (const :tag "Color Name" name)
+ 		 (const :tag "Red-Green-Blue" r-g-b)
+ 		 (const :tag "Hue-Saturation-Value" h-s-v)
+ 		 (cons :tag "Distance on HSV cylinder"
+ 		       (const :tag "Distance from Color" hsv-dist)
+ 		       (color :tag "Source Color Name"))
+ 		 (const :tag "Unsorted" nil))
+   :group 'facemenu
+   :version "23.2")
+ 
+ (defun list-colors-key (color)
+   "Return a list of keys for sorting colors depending on `list-colors-sort'.
+ COLOR is the name of the color.  Filters out a color from the output
+ when return value is nil."
+   (cond
+    ((null list-colors-sort) color)
+    ((eq list-colors-sort 'name)
+     (list color))
+    ((eq list-colors-sort 'r-g-b)
+     (color-values color))
+    ((eq list-colors-sort 'h-s-v)
+     (apply 'rgb-to-hsv (color-values color)))
+    ((eq (car list-colors-sort) 'hsv-dist)
+     (let* ((c-rgb (color-values color))
+ 	   (c-hsv (apply 'rgb-to-hsv c-rgb))
+ 	   (o-hsv (apply 'rgb-to-hsv (color-values (cdr list-colors-sort)))))
+       (unless (and (eq (nth 0 c-rgb) (nth 1 c-rgb)) ; exclude grayscale
+ 		   (eq (nth 1 c-rgb) (nth 2 c-rgb)))
+ 	;; 3D Euclidean distance
+ 	(list (+ (expt (- (abs (- 180 (nth 0 c-hsv))) ; wrap hue as circle
+ 			  (abs (- 180 (nth 0 o-hsv)))) 2)
+ 		 (expt (- (nth 1 c-hsv) (nth 1 o-hsv)) 2)
+ 		 (expt (- (nth 2 c-hsv) (nth 2 o-hsv)) 2))))))))
+ 
  (defun list-colors-display (&optional list buffer-name)
    "Display names of defined colors, and show what they look like.
  If the optional argument LIST is non-nil, it should be a list of
***************
*** 478,483 ****
--- 538,564 ----
    (interactive)
    (when (and (null list) (> (display-color-cells) 0))
      (setq list (list-colors-duplicates (defined-colors)))
+     (when list-colors-sort
+       (setq list (mapcar
+ 		  'car
+ 		  (sort (delq nil (mapcar
+ 				   (lambda (c)
+ 				     (let ((key (list-colors-key (car c))))
+ 				       (and key (cons c key))))
+ 				   list))
+ 			(lambda (a b)
+ 			  (let* ((a-keys (cdr a))
+ 				 (b-keys (cdr b))
+ 				 (a-key (car a-keys))
+ 				 (b-key (car b-keys)))
+ 			    (while (and a-key b-key (eq a-key b-key))
+ 			      (setq a-keys (cdr a-keys) a-key (car a-keys)
+ 				    b-keys (cdr b-keys) b-key (car b-keys)))
+ 			    (cond
+ 			     ((and (numberp a-key) (numberp b-key))
+ 			      (< a-key b-key))
+ 			     ((and (stringp a-key) (stringp b-key))
+ 			      (string< a-key b-key)))))))))
      (when (memq (display-visual-class) '(gray-scale pseudo-color direct-color))
        ;; Don't show more than what the display can handle.
        (let ((lc (nthcdr (1- (display-color-cells)) list)))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Darkening font-lock colors

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > This is the first step to accomplish that (use yellow for the problem
  > > case and just make font-lock-comment-delimiter be identical to
  > > font-lock-comment-face): [...]
  > 
  > I've tried it and I don't like it very much... Compared to my usual
  > color scheme where comments are in red (Debian-patched Emacs), 

The comparison should be to the default now: red for the # (in Makefile)
and white for the comment body.  Using red for comments has been
explicitly rejected here for 8 color dark background display because it
make the text very hard to read.
With 5 foreground colors to choose from (white, black and red exclude),
there's not that much choice to afford to be too picky.

Re: Darkening font-lock colors

[Lennart Borgman]

On Tue, Aug 4, 2009 at 11:27 PM, Johan
Bockgård<bojohan+news@dd.chalmers.se> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>>> A face that has a foreground and a background that is different from
>>> the page looks like a boxed heading. And a chunk of such text doesn't
>>> look like a rectangular text box. It looks like a set of Lego blocks,
>>> with varying right edges due to different line lengths.
>>
>> It sounds like it looks very different on your display. Could you
>> perhaps show an image?
>
> http://www.emacswiki.org/pics/static/bojohan-face-background.png.png


Hm, yes, I see the problem. Thos /* ... */ style comments can probably
look very distracting if there are a lot of them. Sigh.

Are there similar problems with strings and doc strings or are they
more suited for background colors?

Color themes (was: Darkening font-lock colors)

[Juri Linkov]

>> The right solution, of course, is to add a color theming support to Emacs
>> with an easy way to switch themes and to create the `emacs-23.1' color theme.
>
> That would indeed be splendid.
>
> Can't we start merging the existing color-theme package, and iron out
> whatever wrinkles it has?

Do you know how this color-theme package is related to already existing
custom-theme package `cus-theme.el' in Emacs?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Color themes

[joakim]

Juri Linkov <juri@jurta.org> writes:

>>> The right solution, of course, is to add a color theming support to Emacs
>>> with an easy way to switch themes and to create the `emacs-23.1' color theme.
>>
>> That would indeed be splendid.
>>
>> Can't we start merging the existing color-theme package, and iron out
>> whatever wrinkles it has?
>
> Do you know how this color-theme package is related to already existing
> custom-theme package `cus-theme.el' in Emacs?

No, I have no idea.

I only use color-theme to get my favorite color theme,
color-theme-dark-laptop. The main benefit of color-theme is all the nice
themes you can easily try.

If theres already a theme function in Emacs, color-theme:s themes could
be adapted to use that facility instead.

-- 
Joakim Verona

Re: Color themes

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> Do you know how this color-theme package is related to already existing
> custom-theme package `cus-theme.el' in Emacs?

It's not at all related.

I do think it's much easier to use our existing custom theme code to
implement color themes, instead of the (from my last inspection, rather
complicated) machinery in color-theme.el.  Especially if we only want to
provide a small simple selection of color themes, instead of the
multitude provided by color-theme.el.

Re: Color themes

[Leo]

On 2009-08-09 04:04 +0100, Chong Yidong wrote:
> Juri Linkov <juri@jurta.org> writes:
>
>> Do you know how this color-theme package is related to already existing
>> custom-theme package `cus-theme.el' in Emacs?
>
> It's not at all related.
>
> I do think it's much easier to use our existing custom theme code to
> implement color themes, instead of the (from my last inspection, rather
> complicated) machinery in color-theme.el.  Especially if we only want to
> provide a small simple selection of color themes, instead of the
> multitude provided by color-theme.el.

I also don't like color-theme, in particular, how the themes are created
by re-defining all faces. A comprehensive theme could easily run up to a
few thousand lines and it still does not offer 100% coverage, let alone
consistency.

Perhaps a color theme should be defined to be something like a palette
and when a palette is selected defface is forced to only use colors in
it. For example the tango project uses 27 colors.
http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines.

On a side note, Textmate seems to offer the best color themes. See the
following url for many beautiful themes submitted by its users.

http://wiki.macromates.com/Themes/UserSubmittedThemes

Leo

-- 
Leo's Emacs uptime: 5 days, 3 hours, 44 minutes, 7 seconds

Re: Color themes

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> I also don't like color-theme, in particular, how the themes are created
> by re-defining all faces. A comprehensive theme could easily run up to a
> few thousand lines and it still does not offer 100% coverage, let alone
> consistency.
>
> Perhaps a color theme should be defined to be something like a palette
> and when a palette is selected defface is forced to only use colors in
> it.

This is exactly the kind of problem that Custom themes is intended to
solve.  The code for *creating* custom themes is still a little buggy,
but the code for *using* it should work, and we ought to be able to make
use of it to set color themes.

Here's an example.  Create a file called forest-theme.el, with the
contents shown below, and put it in .emacs.d.  Then do M-x enable-theme
RET forest RET, or customize custom-enabled-themes and add `forest' to
the list.

So if we want to use this mechanism to implement color themes, it's just
a matter of adding some *-theme.el files to the load path, and adding a
command to add that theme to custom-enabled-themes.

As you can see, (i) your existing face customizations, if any, will
override the color theme, as they should, and (ii) it doesn't take a lot
of code to define a color theme using this method.


======= start forest-theme.el ============

(deftheme forest
  "Created 2009-08-09.")

(custom-theme-set-faces
 'forest
 '(default ((t (:foreground "wheat" :background "black"))))
 '(font-lock-comment-face ((((class color) (min-colors 88)) (:foreground "medium sea green"))))
 '(font-lock-constant-face ((((class color) (min-colors 88)) (:foreground "turquoise"))))
 '(font-lock-function-name-face ((((class color) (min-colors 88)) (:foreground "pale green"))))
 '(font-lock-keyword-face ((((class color) (min-colors 88)) (:foreground "white"))))
 '(font-lock-string-face ((((class color) (min-colors 88)) (:foreground "dark khaki"))))
 '(font-lock-type-face ((((class color) (min-colors 88)) (:foreground "medium aquamarine"))))
 '(font-lock-variable-name-face ((((class color) (min-colors 88)) (:foreground "yellow green"))))
 '(font-lock-warning-face ((((class color) (min-colors 88)) (:foreground "salmon1"))))
 '(font-lock-builtin-face ((((class color) (min-colors 88)) (:foreground "LightSteelBlue"))))
 '(region ((((class color) (min-colors 88)) (:foreground "white" :background "dark green"))))
 '(highlight ((((class color) (min-colors 88)) (:foreground "white" :background "dark green")))))

(provide-theme 'forest)

======= end forest-theme.el ============

Re: Color themes

[CHENG Gao]

*On Sun, 09 Aug 2009 12:18:01 -0400
* Also sprach Chong Yidong <cyd@stupidchicken.com>:

> Leo <sdl.web@gmail.com> writes:
>
>> I also don't like color-theme, in particular, how the themes are created
>> by re-defining all faces. A comprehensive theme could easily run up to a
>> few thousand lines and it still does not offer 100% coverage, let alone
>> consistency.
>>
>> Perhaps a color theme should be defined to be something like a palette
>> and when a palette is selected defface is forced to only use colors in
>> it.
>
> This is exactly the kind of problem that Custom themes is intended to
> solve.  The code for *creating* custom themes is still a little buggy,
> but the code for *using* it should work, and we ought to be able to make
> use of it to set color themes.
>
> Here's an example.  Create a file called forest-theme.el, with the
> contents shown below, and put it in .emacs.d.  Then do M-x enable-theme
> RET forest RET, or customize custom-enabled-themes and add `forest' to
> the list.
>
> So if we want to use this mechanism to implement color themes, it's just
> a matter of adding some *-theme.el files to the load path, and adding a
> command to add that theme to custom-enabled-themes.
>
> As you can see, (i) your existing face customizations, if any, will
> override the color theme, as they should, and (ii) it doesn't take a lot
> of code to define a color theme using this method.
>
>
> ======= start forest-theme.el ============
>
> (deftheme forest
>   "Created 2009-08-09.")
>
> (custom-theme-set-faces
>  'forest
>  '(default ((t (:foreground "wheat" :background "black"))))
>  '(font-lock-comment-face ((((class color) (min-colors 88)) (:foreground "medium sea green"))))
>  '(font-lock-constant-face ((((class color) (min-colors 88)) (:foreground "turquoise"))))
>  '(font-lock-function-name-face ((((class color) (min-colors 88)) (:foreground "pale green"))))
>  '(font-lock-keyword-face ((((class color) (min-colors 88)) (:foreground "white"))))
>  '(font-lock-string-face ((((class color) (min-colors 88)) (:foreground "dark khaki"))))
>  '(font-lock-type-face ((((class color) (min-colors 88)) (:foreground "medium aquamarine"))))
>  '(font-lock-variable-name-face ((((class color) (min-colors 88)) (:foreground "yellow green"))))
>  '(font-lock-warning-face ((((class color) (min-colors 88)) (:foreground "salmon1"))))
>  '(font-lock-builtin-face ((((class color) (min-colors 88)) (:foreground "LightSteelBlue"))))
>  '(region ((((class color) (min-colors 88)) (:foreground "white" :background "dark green"))))
>  '(highlight ((((class color) (min-colors 88)) (:foreground "white" :background "dark green")))))
>
> (provide-theme 'forest)
>
> ======= end forest-theme.el ============

I must say I like this way very much. I just tested your theme, and it
works, though not super gorgeous :-P


-- 
Volo, non valeo

Re: Color themes

[Lennart Borgman]

On Sun, Aug 9, 2009 at 6:18 PM, Chong Yidong<cyd@stupidchicken.com> wrote:

> This is exactly the kind of problem that Custom themes is intended to
> solve.  The code for *creating* custom themes is still a little buggy,
> but the code for *using* it should work, and we ought to be able to make
> use of it to set color themes.
>
> Here's an example.  Create a file called forest-theme.el, with the
> contents shown below, and put it in .emacs.d.  Then do M-x enable-theme
> RET forest RET, or customize custom-enabled-themes and add `forest' to
> the list.
>
> So if we want to use this mechanism to implement color themes, it's just
> a matter of adding some *-theme.el files to the load path, and adding a
> command to add that theme to custom-enabled-themes.
>
> As you can see, (i) your existing face customizations, if any, will
> override the color theme, as they should, and (ii) it doesn't take a lot
> of code to define a color theme using this method.


Thanks for the example. This looks very good (I don't mean the colors ... ;-).

I was kind of reinventing that. Sigh.

Could we please get this working? Making it easy to use etc. Good
prompting for themes so it is easy to switch, easy to reset ... Maybe
some kind of "list-themes" with the doc strings...

Then we can also make those Mac-themes, w32-themes,
emacs-as-it-always-was-theme ...

Re: Color themes

[joakim]

Chong Yidong <cyd@stupidchicken.com> writes:

> Leo <sdl.web@gmail.com> writes:
>
>> I also don't like color-theme, in particular, how the themes are created
>> by re-defining all faces. A comprehensive theme could easily run up to a
>> few thousand lines and it still does not offer 100% coverage, let alone
>> consistency.
>>
>> Perhaps a color theme should be defined to be something like a palette
>> and when a palette is selected defface is forced to only use colors in
>> it.
>
> This is exactly the kind of problem that Custom themes is intended to
> solve.  The code for *creating* custom themes is still a little buggy,
> but the code for *using* it should work, and we ought to be able to make
> use of it to set color themes.
>
> Here's an example.  Create a file called forest-theme.el, with the
> contents shown below, and put it in .emacs.d.  Then do M-x enable-theme
> RET forest RET, or customize custom-enabled-themes and add `forest' to
> the list.
>
> So if we want to use this mechanism to implement color themes, it's just
> a matter of adding some *-theme.el files to the load path, and adding a
> command to add that theme to custom-enabled-themes.
>
> As you can see, (i) your existing face customizations, if any, will
> override the color theme, as they should, and (ii) it doesn't take a lot
> of code to define a color theme using this method.

While I havent tested this, it seems great!

Can we somehow create a machine translator from color-theme.el to
custom-theme? 

>
>
> ======= start forest-theme.el ============
>
> (deftheme forest
>   "Created 2009-08-09.")
>
> (custom-theme-set-faces
>  'forest
>  '(default ((t (:foreground "wheat" :background "black"))))
>  '(font-lock-comment-face ((((class color) (min-colors 88)) (:foreground "medium sea green"))))
>  '(font-lock-constant-face ((((class color) (min-colors 88)) (:foreground "turquoise"))))
>  '(font-lock-function-name-face ((((class color) (min-colors 88)) (:foreground "pale green"))))
>  '(font-lock-keyword-face ((((class color) (min-colors 88)) (:foreground "white"))))
>  '(font-lock-string-face ((((class color) (min-colors 88)) (:foreground "dark khaki"))))
>  '(font-lock-type-face ((((class color) (min-colors 88)) (:foreground "medium aquamarine"))))
>  '(font-lock-variable-name-face ((((class color) (min-colors 88)) (:foreground "yellow green"))))
>  '(font-lock-warning-face ((((class color) (min-colors 88)) (:foreground "salmon1"))))
>  '(font-lock-builtin-face ((((class color) (min-colors 88)) (:foreground "LightSteelBlue"))))
>  '(region ((((class color) (min-colors 88)) (:foreground "white" :background "dark green"))))
>  '(highlight ((((class color) (min-colors 88)) (:foreground "white" :background "dark green")))))
>
> (provide-theme 'forest)
>
> ======= end forest-theme.el ============
>
-- 
Joakim Verona

Re: Darkening font-lock colors

[Juri Linkov]

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

>>> Suggestions welcome.  I'm afraid I don't have the time to tinker around
>>> finding an optimal color scheme---I just wanted to fix the legibility
>>> problem.  If you can come up with something better, let us know.
>
> I think there are two essential things to cover:
>
> - Readability, ie luminosity color contrast.
> - Color distinguishability.

Yes, distinguishability is an important thing, and the current colors
lack it.  font-lock-builtin is indistinguishable from font-lock-string-face,
and font-lock-variable is indistinguishable from font-lock-comment
because generally dark colors are indistinguishable from black
foreground color as can be seen on the screenshot below.

I propose to use Magenta3 for font-lock-builtin, PaleVioletRed3 for
font-lock-string and return font-lock-variable back to DarkGoldenrod.

These colors are:

1. Readable;
2. Clearly distinguishable from other colors;
3. Close to original colors.

This is a comparison chart of 3 color schemes: Emacs22, current colors
in CVS, and proposed new colors:


[-- Attachment #2: facetest.png --]
[-- Type: image/png, Size: 7161 bytes --]

[-- Attachment #3: Type: text/plain, Size: 103 bytes --]


And to help comparing them visually below are some samples of using
there color schemes.

* Emacs22:


[-- Attachment #4: emacs22.png --]
[-- Type: image/png, Size: 6227 bytes --]

[-- Attachment #5: Type: text/plain, Size: 27 bytes --]


* Current colors in CVS:


[-- Attachment #6: cvs.png --]
[-- Type: image/png, Size: 6205 bytes --]

[-- Attachment #7: Type: text/plain, Size: 25 bytes --]


* Proposed new colors:


[-- Attachment #8: new.png --]
[-- Type: image/png, Size: 6250 bytes --]

[-- Attachment #9: Type: text/plain, Size: 45 bytes --]


-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Darkening font-lock colors

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > >>> Suggestions welcome.  I'm afraid I don't have the time to tinker around
  > >>> finding an optimal color scheme---I just wanted to fix the legibility
  > >>> problem.  If you can come up with something better, let us know.
  > >
  > > I think there are two essential things to cover:
  > >
  > > - Readability, ie luminosity color contrast.
  > > - Color distinguishability.
  > 
  > Yes, distinguishability is an important thing, and the current colors
  > lack it.  font-lock-builtin is indistinguishable from font-lock-string-face,
  > and font-lock-variable is indistinguishable from font-lock-comment
  > because generally dark colors are indistinguishable from black
  > foreground color as can be seen on the screenshot below.
  > 
  > I propose to use Magenta3 for font-lock-builtin, PaleVioletRed3 for
  > font-lock-string and return font-lock-variable back to DarkGoldenrod.
  > 
  > These colors are:
  > 
  > 1. Readable;
  > 2. Clearly distinguishable from other colors;
  > 3. Close to original colors.
  > 
  > This is a comparison chart of 3 color schemes: Emacs22, current colors
  > in CVS, and proposed new colors:

Thanks for doing this, if you are looking for opinions: your way is
better that both the current CVS and emacs22.

Re: Darkening font-lock colors

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > I propose to use Magenta3 for font-lock-builtin, PaleVioletRed3 for
>   > font-lock-string and return font-lock-variable back to DarkGoldenrod.
>   > 
>   > These colors are:
>   > 
>   > 1. Readable;
>   > 2. Clearly distinguishable from other colors;
>   > 3. Close to original colors.
>   > 
>   > This is a comparison chart of 3 color schemes: Emacs22, current colors
>   > in CVS, and proposed new colors:
>
> Thanks for doing this, if you are looking for opinions: your way is
> better that both the current CVS and emacs22.

I disagree.  Juri's proposed colors look way too faded out -- i.e., hard
to read (emacs22 colors suffered from the same problem), and are more
irritating to boot (magenta should not be used for text!).

The current CVS colors are better.

-Miles

-- 
Inhumanity, n. One of the signal and characteristic qualities of humanity.

Re: Color themes

[Leo]

2009/8/9 Chong Yidong <cyd@stupidchicken.com>:
> Leo <sdl.web@gmail.com> writes:
>
>> I also don't like color-theme, in particular, how the themes are created
>> by re-defining all faces. A comprehensive theme could easily run up to a
>> few thousand lines and it still does not offer 100% coverage, let alone
>> consistency.
>>
>> Perhaps a color theme should be defined to be something like a palette
>> and when a palette is selected defface is forced to only use colors in
>> it.
>
> This is exactly the kind of problem that Custom themes is intended to
> solve.  The code for *creating* custom themes is still a little buggy,
> but the code for *using* it should work, and we ought to be able to make
> use of it to set color themes.
>
> Here's an example.  Create a file called forest-theme.el, with the
> contents shown below, and put it in .emacs.d.  Then do M-x enable-theme
> RET forest RET, or customize custom-enabled-themes and add `forest' to
> the list.
>
> So if we want to use this mechanism to implement color themes, it's just
> a matter of adding some *-theme.el files to the load path, and adding a
> command to add that theme to custom-enabled-themes.
>
> As you can see, (i) your existing face customizations, if any, will
> override the color theme, as they should, and (ii) it doesn't take a lot
> of code to define a color theme using this method.
>
>
> ======= start forest-theme.el ============
>
> (deftheme forest
>  "Created 2009-08-09.")
>
> (custom-theme-set-faces
>  'forest
>  '(default ((t (:foreground "wheat" :background "black"))))
>  '(font-lock-comment-face ((((class color) (min-colors 88)) (:foreground "medium sea green"))))
>  '(font-lock-constant-face ((((class color) (min-colors 88)) (:foreground "turquoise"))))
>  '(font-lock-function-name-face ((((class color) (min-colors 88)) (:foreground "pale green"))))
>  '(font-lock-keyword-face ((((class color) (min-colors 88)) (:foreground "white"))))
>  '(font-lock-string-face ((((class color) (min-colors 88)) (:foreground "dark khaki"))))
>  '(font-lock-type-face ((((class color) (min-colors 88)) (:foreground "medium aquamarine"))))
>  '(font-lock-variable-name-face ((((class color) (min-colors 88)) (:foreground "yellow green"))))
>  '(font-lock-warning-face ((((class color) (min-colors 88)) (:foreground "salmon1"))))
>  '(font-lock-builtin-face ((((class color) (min-colors 88)) (:foreground "LightSteelBlue"))))
>  '(region ((((class color) (min-colors 88)) (:foreground "white" :background "dark green"))))
>  '(highlight ((((class color) (min-colors 88)) (:foreground "white" :background "dark green")))))
>
> (provide-theme 'forest)
>
> ======= end forest-theme.el ============

Thank you Chong.

I failed to see how consistency can be reached through this.

For example, if a package define faces that do not inherit from the
faces in the theme, then enabling the theme won't affect them, right?

I am thinking about if each buffer is an icon, how to make sure they
look like, for example, tango by using the 28 colors in its style
guide only.

Leo

Re: Color themes

[Juri Linkov]

> I am thinking about if each buffer is an icon, how to make sure they
> look like, for example, tango by using the 28 colors in its style
> guide only.

Color themes and palettes are different things but both are useful.
A color theme redefines every face individually whereas a palette
reduces them to a list of predefined colors.

Actually, Emacs already has palette support on text-only terminals
with a small number of colors with the help of the function
`tty-color-approximate' that finds the closest color among the
known colors.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Darkening font-lock colors

[Juri Linkov]

>> Thanks for doing this, if you are looking for opinions: your way is
>> better that both the current CVS and emacs22.
>
> I disagree.  Juri's proposed colors look way too faded out -- i.e., hard
> to read (emacs22 colors suffered from the same problem), and are more
> irritating to boot

I agree that my colors are not ideal but they are better than
unreadable emacs22 colors and better than the current CVS colors
that are indistinguishable from each other and from the default
black foreground color.

> (magenta should not be used for text!).

Magenta should not be used on a dark background where a better color
is violet.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Color themes

[Leo]

On 2009-08-11 00:48 +0100, Juri Linkov wrote:
>> I am thinking about if each buffer is an icon, how to make sure they
>> look like, for example, tango by using the 28 colors in its style
>> guide only.
>
> Color themes and palettes are different things but both are useful.
> A color theme redefines every face individually whereas a palette
> reduces them to a list of predefined colors.
>
> Actually, Emacs already has palette support on text-only terminals
> with a small number of colors with the help of the function
> `tty-color-approximate' that finds the closest color among the
> known colors.

Well if you consider that a palette, it is one forced by the limitation
of the terminal. So you can't carefully pick good colours to form a
palette for text editing.

-- 
Leo's Emacs uptime: 7 days, 1 hour, 1 minute, 39 seconds

Re: Color themes

[Chong Yidong]

Leo <sdl.web@googlemail.com> writes:

> I failed to see how consistency can be reached through this.
>
> For example, if a package define faces that do not inherit from the
> faces in the theme, then enabling the theme won't affect them, right?

Most faces inherit from the basic faces (default, bold, italic, region,
etc.) plus the font-lock faces.  Or at least they should.

Re: Color themes

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Leo <sdl.web@googlemail.com> writes:
  > 
  > > I failed to see how consistency can be reached through this.
  > >
  > > For example, if a package define faces that do not inherit from the
  > > faces in the theme, then enabling the theme won't affect them, right?
  > 
  > Most faces inherit from the basic faces (default, bold, italic, region,
  > etc.) plus the font-lock faces.  

Unfortunately that is not always true. :-(
emacs -Q 
M-x list-faces-display 
will show a few that do not: buffer-menu-buffer, mode-line-buffer-id, 
mode-line-emphasis, and that is just looking for things that look bold.

  > Or at least they should.

Agreed.   

RE: Color themes

[Drew Adams]

>   > Most faces inherit from the basic faces (default, bold, 
>   > italic, region, etc.) plus the font-lock faces.  
> 
> Unfortunately that is not always true. :-(
>
>   > Or at least they should.
> 
> Agreed.   

Why?

(No reasons given.)

RE: Color themes

[Drew Adams]

> Most faces inherit from the basic faces (default, bold, 
> italic, region, etc.) plus the font-lock faces.
> Or at least they should.

Huh? Where does it say that? Since when?

What possible reason could there be for saying that it's OK to inherit from
basic face `escape-glyph' (for example) but not OK to define your own face
without inheriting from any "basic face" or a font-lock face. What's so special
about the "basic faces" and font-lock faces? When you defined face
`escape-glyph', what made you decide it was a "basic face"?

I find nothing anywhere in the Emacs or Elisp manual that suggests that
inheriting is good and not inheriting is bad, let alone that one should inherit
(ultimately) from one of the "basic faces" or a font-lock face.

And what makes a face a "basic face", anyway? 

I see nothing in the doc that even defines any notion of "basic face". There is
no mention of it in the Emacs manual. The only use of that term in the Elisp
manual is in the example defface for face `region' (only in its doc string and
:group).

There is a customize group named `basic-faces' (with 35 faces in it), but we all
know how little meaning to ascribe to customize groups or their names.

And if someone uses :group 'basic-faces in a defface, then presumably that
creates a new basic face? Belonging to :group `basic-faces' certainly can't be
the real meaning of the concept "basic face".

So do we now have a new guideline - "Thou shalt inherit from a basic face" -
that has no meaning? Next thing you know, someone will add that commandment to
the doc, having picked it up from your post. Another rule for the Emacs
Catechism, with no reasons given...

Re: Color themes

[Leo]

Hi Yidong,

On 2009-08-11 04:58 +0100, Chong Yidong wrote:
>> For example, if a package define faces that do not inherit from the
>> faces in the theme, then enabling the theme won't affect them, right?
>
> Most faces inherit from the basic faces (default, bold, italic, region,
> etc.) plus the font-lock faces.  Or at least they should.

I see inheritance as a convenient tool for defining new faces, but not
an effective tool for enforce consistency. Even if all faces inherit
from more basic ones, they can still choose to use different colours and
in reality this is what happens.

-- 
Leo's Emacs uptime: 7 days, 8 hours, 53 minutes, 56 seconds

Re: Color themes

[ferkiwi]

On Tue, Aug 11, 2009 at 10:59 AM, Leo<sdl.web@gmail.com> wrote:
> I see inheritance as a convenient tool for defining new faces, but not
> an effective tool for enforce consistency. Even if all faces inherit
> from more basic ones, they can still choose to use different colours and
> in reality this is what happens.

Personally, when I have to choose a color theme I prefer the theme
that has the most different and distinguishable colors. There are some
color-themes that have the very same color for many different faces
and I think that's defeating the point of selective highlighting. I
like when I'm able to know what's the role of a word by looking at its
unique color. I like to be able to give specific colors to
flymake-errline or hl-line faces, they would be kind of unusable if
they had the same colors from a reduced basic set (I can't use
hl-line-mode with emacs in a terminal because of this, it's not
comfortable for me to have such a bright line due to the reduced set
of terminal colors).

So, while I agree that inheriting colors is good for making it easy to
develop new themes, I think that allowing the themes to change
selectively the color of "non-standard" faces is also good, imho. And
I think this two things are not mutually excluding.

--
Fernando