Color themes

Color themes

[Chong Yidong]

Many of you are probably aware of a package called color-theme.el,
currently maintained by Xavier Maillard.  This package provides a
relatively easy way to choose from a list of pre-selected "color
themes" for font-lock keywords.  I think this kind of functionality
would be good.  For new users who dislike the default color palette,
there's currently no easy way to choose a different palette.

Ideally, there should be a submenu in the menu-bar, under Options, to
select a color theme (or whatever we end up calling it).

However, I'm ambivalent about how color-theme.el is written.  From a
perfunctory inspection of the code, it looks like it sets up some
infrastructure for defining color-themes that I'm not sure is a good
fit for Emacs.  In particular, it might be cleaner to define color
themes using Custom Themes, which were implemented in Emacs 22 and
meshes with the Customize facility.  I might be wrong, however, so
comments are welcome.

At this early stage, I haven't looked into the copyright assignment
issue for color-theme.el.  Assuming papers aren't a problem, I'm
thinking we could absorb part of the color-theme project, i.e. the
color settings that they've collected, and rewrite the theme-choosing
infrastructure based on Custom Themes.

Any thoughts?

Re: Color themes

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Many of you are probably aware of a package called color-theme.el,
  > currently maintained by Xavier Maillard.  This package provides a
  > relatively easy way to choose from a list of pre-selected "color
  > themes" for font-lock keywords.  I think this kind of functionality
  > would be good.  For new users who dislike the default color palette,
  > there's currently no easy way to choose a different palette.
  > 
  > Ideally, there should be a submenu in the menu-bar, under Options, to
  > select a color theme (or whatever we end up calling it).
  > 
  > However, I'm ambivalent about how color-theme.el is written.  From a
  > perfunctory inspection of the code, it looks like it sets up some
  > infrastructure for defining color-themes that I'm not sure is a good
  > fit for Emacs.  In particular, it might be cleaner to define color
  > themes using Custom Themes, which were implemented in Emacs 22 and
  > meshes with the Customize facility.  I might be wrong, however, so
  > comments are welcome.
  > 
  > At this early stage, I haven't looked into the copyright assignment
  > issue for color-theme.el.  Assuming papers aren't a problem, I'm
  > thinking we could absorb part of the color-theme project, i.e. the
  > color settings that they've collected, and rewrite the theme-choosing
  > infrastructure based on Custom Themes.
  > 
  > Any thoughts?

One main problem with color-theme.el is that it smashes the face
definitions.  
With multi-tty and the default face definitions you can do things like:

emacs -f server-start

rxvt -fg white -bg black  
and in rxvt do emacsclient -t

then start another rxvt with a different fg/bg:
rxvt -fg black -bg white 
and in there do emacsclient -t

[rxvt not xterm with emacs knows how to find out the default fg/bg color].

All the emacs/eamcsclient frames in the example above will get the
correct face definitions for the type of display they run on. 
That does not work anymore if one uses color-theme.el (and quite likely
Custom Themes).

Just my 2 cents.

Re: Color themes

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Fri, 29 Feb 2008 15:49:00 -0800
> Cc: emacs-devel@gnu.org
> 
> With multi-tty and the default face definitions you can do things like:
> 
> emacs -f server-start
> 
> rxvt -fg white -bg black  
> and in rxvt do emacsclient -t
> 
> then start another rxvt with a different fg/bg:
> rxvt -fg black -bg white 
> and in there do emacsclient -t
> 
> [rxvt not xterm with emacs knows how to find out the default fg/bg color].
> 
> All the emacs/eamcsclient frames in the example above will get the
> correct face definitions for the type of display they run on. 
> That does not work anymore if one uses color-theme.el (and quite likely
> Custom Themes).

OTOH, perhaps whoever uses color themes wants all their frames to use
the same face definitions?

Re: Color themes

[Eric Lilja]

Chong Yidong wrote:
> Many of you are probably aware of a package called color-theme.el,
> currently maintained by Xavier Maillard.  This package provides a
> relatively easy way to choose from a list of pre-selected "color
> themes" for font-lock keywords.  I think this kind of functionality
> would be good.  For new users who dislike the default color palette,
> there's currently no easy way to choose a different palette.
> 
> Ideally, there should be a submenu in the menu-bar, under Options, to
> select a color theme (or whatever we end up calling it).
> 
> However, I'm ambivalent about how color-theme.el is written.  From a
> perfunctory inspection of the code, it looks like it sets up some
> infrastructure for defining color-themes that I'm not sure is a good
> fit for Emacs.  In particular, it might be cleaner to define color
> themes using Custom Themes, which were implemented in Emacs 22 and
> meshes with the Customize facility.  I might be wrong, however, so
> comments are welcome.
> 
> At this early stage, I haven't looked into the copyright assignment
> issue for color-theme.el.  Assuming papers aren't a problem, I'm
> thinking we could absorb part of the color-theme project, i.e. the
> color settings that they've collected, and rewrite the theme-choosing
> infrastructure based on Custom Themes.
> 
> Any thoughts?
> 
> 
> 

I'm, sad to say, not a developer, but I'd love to see color theme as an 
official emacs package! Hopefully it can be made to play nice with all 
other emacs features. Sorry for the noise but I felt I needed to say that.

- Eric

Re: Color themes

[Xavier Maillard]

Hi,

   Any thoughts?

As you have mentionned it, I am the current maintainer of this
package. Currently, there is not much developments done *but*
there is many things to do. I do not considerate the package
status to be mature enough.

Yes it works, yes it is stable but there are many things planned
before it could eventually enter GNU Emacs TRUNK.

If you have questions regarding legal status or anything related
to this package (enhancements to do, etc.) I would be happy to
discuss them.

Current development is stalled but I received many requests by
mail (new themes, bug reports, etc.) and I am planning to
resurrect this project as soon as I get enough time to do it
seriously. Then will come the time to release 7.0 version that
would probably fit better and match with criterias to be part of
the GNU Emacs mainline development.

Regards,

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

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:

  > 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

[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

[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

[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

[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

[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

[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

[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

[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

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: 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: 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