list-colors-display: display all color names

list-colors-display: display all color names

[Juri Linkov]

It's too bad that `list-colors-display' currently doesn't contain
all variants of color names with alternative spellings and spaces.
When I put a color name into the search ring in one buffer and then
isearch it with C-s C-s in the *Colors* buffer to see how the color
looks, often the search fails.  I need to edit the search string
to add spaces or change the spelling of color names and to try again.
This is very inconvenient.  The *Colors* buffer should contain all
color names, even duplicates with the same color values.

I understand that the reason to remove color names with the same
color value was to reduce the amount of lines in the *Colors* buffer.
So I propose the patch which displays all duplicate color names on the
same line.  When there is only one color name, it is displayed in both
background and foreground color examples.  When there are two duplicate
color names, one of them is displayed in background, and another in
foreground color.  When there are more than two color names, the first
of them is displayed in the background example, and all others are
separated by comma in the foreground color example.  For instance,

white                   white
black                   black
dark slate gray         DarkSlateGray, dark slate grey, DarkSlateGrey
dim gray                DimGray, dim grey, DimGrey
slate gray              SlateGray, slate grey, SlateGrey
light slate gray        LightSlateGray, light slate grey, LightSlateGrey
gray                    grey
light grey              LightGrey, light gray, LightGray
midnight blue           MidnightBlue
navy                    navy blue, NavyBlue

This eliminates the need to identify duplicate colors by the name.

Index: lisp/facemenu.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/facemenu.el,v
retrieving revision 1.73
diff -u -r1.73 facemenu.el
--- lisp/facemenu.el	4 Sep 2004 19:11:18 -0000	1.73
+++ lisp/facemenu.el	26 Dec 2004 17:04:43 -0000
@@ -471,50 +471,59 @@
       col)))
 
 ;;;###autoload
-(defun list-colors-display (&optional list)
+(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
-colors to display.  Otherwise, this command computes a list
-of colors that the current display can handle."
+colors to display.  Otherwise, this command computes a list of
+colors that the current display can handle.  If the optional
+argument BUFFER-NAME is nil, it defaults to *Colors*."
   (interactive)
   (when (and (null list) (> (display-color-cells) 0))
-    (setq list (defined-colors))
-    ;; Delete duplicate colors.
-
-    ;; Identify duplicate colors by the name rather than the color
-    ;; value.  For example, on MS-Windows, logical colors are added to
-    ;; the list that might have the same value but have different
-    ;; names and meanings.  For example, `SystemMenuText' (the color
-    ;; w32 uses for the text in menu entries) and `SystemWindowText'
-    ;; (the default color w32 uses for the text in windows and
-    ;; dialogs) may be the same display color and be adjacent in the
-    ;; list.  Detecting duplicates by name insures that both of these
-    ;; colors remain despite identical color values.
-    (let ((l list))
-      (while (cdr l)
-	(if (facemenu-color-name-equal (car l) (car (cdr l)))
-	    (setcdr l (cdr (cdr l)))
-	  (setq l (cdr l)))))
+    (setq list (list-colors-duplicates (defined-colors)))
     (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)))
 	(if lc
 	    (setcdr lc nil)))))
-  (with-output-to-temp-buffer "*Colors*"
+  (with-output-to-temp-buffer (or buffer-name "*Colors*")
     (save-excursion
       (set-buffer standard-output)
-      (let (s)
-	(while list
-	  (setq s (point))
-	  (insert (car list))
-	  (indent-to 20)
-	  (put-text-property s (point) 'face
-			     (cons 'background-color (car list)))
-	  (setq s (point))
-	  (insert "  " (car list) "\n")
-	  (put-text-property s (point) 'face
-			     (cons 'foreground-color (car list)))
-	  (setq list (cdr list)))))))
+      (dolist (color list)
+	(or (consp color) (setq color (list color)))
+	(put-text-property
+	 (prog1 (point)
+	   (insert (car color))
+	   (indent-to 22))
+	 (point)
+	 'face (cons 'background-color (car color)))
+	(put-text-property
+	 (prog1 (point)
+	   (insert "  "
+		   (if (cdr color)
+		       (mapconcat 'identity (reverse (cdr color)) ", ")
+		     (car color))
+		   "\n"))
+	 (point)
+	 'face (cons 'foreground-color (car color)))))))
+
+(defun list-colors-duplicates (&optional list)
+  "Return a list of colors with grouped duplicate colors.
+If a color has no duplicates, then the element of the returned list
+has the form '(COLOR-NAME).  The element of the returned list with
+duplicate colors has the form '(COLOR-NAME DUPLICATE-COLOR-NAME ...).
+This function uses the predicate `facemenu-color-equal' to compare
+color names.  If the optional argument LIST is non-nil, it should
+be a list of colors to display.  Otherwise, this function uses
+a list of colors that the current display can handle."
+  (let* ((list (mapcar 'list (or list (defined-colors))))
+	 (l list))
+    (while (cdr l)
+      (if (facemenu-color-equal (car (car l)) (car (car (cdr l))))
+	  (progn
+	    (setcdr (car l) (cons (car (car (cdr l))) (cdr (car l))))
+	    (setcdr l (cdr (cdr l))))
+	(setq l (cdr l))))
+    list))
 
 (defun facemenu-color-equal (a b)
   "Return t if colors A and B are the same color.
@@ -525,22 +534,6 @@
   (cond ((equal a b) t)
 	((equal (color-values a) (color-values b)))))
 
-(defun facemenu-color-name-equal (a b)
-  "Return t if colors A and B are the same color.
-A and B should be strings naming colors.  These names are
-downcased, stripped of spaces and the string `grey' is turned
-into `gray'.  This accommodates alternative spellings of colors
-found commonly in the list.  It returns nil if the colors differ."
-  (progn
-    (setq a (replace-regexp-in-string "grey" "gray"
-            (replace-regexp-in-string " " ""
-             (downcase a)))
-         b (replace-regexp-in-string "grey" "gray"
-            (replace-regexp-in-string " " ""
-             (downcase b))))
-
-    (equal a b)))
-
 (defun facemenu-add-face (face &optional start end)
   "Add FACE to text between START and END.
 If START is nil or START to END is empty, add FACE to next typed character

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

Re: list-colors-display: display all color names

[Richard Stallman]

      When there are more than two color names, the first
    of them is displayed in the background example, and all others are
    separated by comma in the foreground color example.  For instance,

I like this change, but it needs to set truncate-lines to t
in that buffer in case there are so many names that they 
don't all fit.

Also, on each line please sort all the various names.

Re: list-colors-display: display all color names

[Michael Mauger]

Juri Linkov <juri <at> jurta.org> writes:

> 
> It's too bad that `list-colors-display' currently doesn't contain
> all variants of color names with alternative spellings and spaces.
> When I put a color name into the search ring in one buffer and then
> isearch it with C-s C-s in the *Colors* buffer to see how the color
> looks, often the search fails.  I need to edit the search string
> to add spaces or change the spelling of color names and to try again.
> This is very inconvenient.  The *Colors* buffer should contain all
> color names, even duplicates with the same color values.
> 
> ...
> 
> This eliminates the need to identify duplicate colors by the name.
> 

I like this idea except for this last bit.  

We changed `list-colors-display' to match by name rather than color value so 
that if "System" colors were added to the list they wouldn't be merged 
together.  The examples in the original post are all aliases for the same 
color.  They can be used interchangably on any platform with reasonable results.

The System colors are designed to make window manager theme colors available 
within Emacs so that faces can follow the corresponding colors in the rest of 
the GUI.  If the colors "SystemMenuText" and "SystemText" happen to be mapped 
to the same color it does not mean that they are aliases for the same color.  
Under a different window manager theme they might be different colors.  In this 
case these color names are not interchangable and should not be presented as if 
they were alaises.

The comment removed from the code was supposed to explain this clearly.  
Obviously it did not.

Does matching on the name rather than the color value result in a different 
output with your other changes?  Should we match on color value unless the name 
starts with the string "System"?

-- 
Michael Mauger

Re: list-colors-display: display all color names

[Juri Linkov]

Michael Mauger <mmaug@yahoo.com> writes:
> Does matching on the name rather than the color value result in a different 
> output with your other changes?  Should we match on color value unless the name 
> starts with the string "System"?

The problem is that "SystemMenuText" and "SystemText" are not color names,
but rather color settings.  Matching them by name is not a reliable solution.
There is a likelihood of non-Windows color names starting with the string
"System", or Windows colors having name without the string "System".

I looked a little at Windows-related Emacs files, and see that the
variable `w32-default-color-map' does not contain Window theme colors.
I think it could be used to match Window theme color by a condition like

    (not (and (boundp 'w32-default-color-map)
         (not (assoc (car (car l)) w32-default-color-map))))

I don't use Windows, so I can't check it.  Could you see if all names are
displayed correctly?  Then do you have any objections to the following patch?

Index: lisp/facemenu.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/facemenu.el,v
retrieving revision 1.73
diff -u -r1.73 facemenu.el
--- lisp/facemenu.el	4 Sep 2004 19:11:18 -0000	1.73
+++ lisp/facemenu.el	29 Dec 2004 19:02:09 -0000
@@ -471,50 +471,66 @@
       col)))
 
 ;;;###autoload
-(defun list-colors-display (&optional list)
+(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
-colors to display.  Otherwise, this command computes a list
-of colors that the current display can handle."
+colors to display.  Otherwise, this command computes a list of
+colors that the current display can handle.  If the optional
+argument BUFFER-NAME is nil, it defaults to *Colors*."
   (interactive)
   (when (and (null list) (> (display-color-cells) 0))
-    (setq list (defined-colors))
-    ;; Delete duplicate colors.
-
-    ;; Identify duplicate colors by the name rather than the color
-    ;; value.  For example, on MS-Windows, logical colors are added to
-    ;; the list that might have the same value but have different
-    ;; names and meanings.  For example, `SystemMenuText' (the color
-    ;; w32 uses for the text in menu entries) and `SystemWindowText'
-    ;; (the default color w32 uses for the text in windows and
-    ;; dialogs) may be the same display color and be adjacent in the
-    ;; list.  Detecting duplicates by name insures that both of these
-    ;; colors remain despite identical color values.
-    (let ((l list))
-      (while (cdr l)
-	(if (facemenu-color-name-equal (car l) (car (cdr l)))
-	    (setcdr l (cdr (cdr l)))
-	  (setq l (cdr l)))))
+    (setq list (list-colors-duplicates (defined-colors)))
     (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)))
 	(if lc
 	    (setcdr lc nil)))))
-  (with-output-to-temp-buffer "*Colors*"
+  (with-output-to-temp-buffer (or buffer-name "*Colors*")
     (save-excursion
       (set-buffer standard-output)
-      (let (s)
-	(while list
-	  (setq s (point))
-	  (insert (car list))
-	  (indent-to 20)
-	  (put-text-property s (point) 'face
-			     (cons 'background-color (car list)))
-	  (setq s (point))
-	  (insert "  " (car list) "\n")
-	  (put-text-property s (point) 'face
-			     (cons 'foreground-color (car list)))
-	  (setq list (cdr list)))))))
+      (setq truncate-lines t)
+      (dolist (color list)
+	(if (consp color)
+	    (if (cdr color)
+		(setq color (sort color (lambda (a b)
+					  (string< (downcase a)
+						   (downcase b))))))
+	  (setq color (list color)))
+	(put-text-property
+	 (prog1 (point)
+	   (insert (car color))
+	   (indent-to 22))
+	 (point)
+	 'face (cons 'background-color (car color)))
+	(put-text-property
+	 (prog1 (point)
+	   (insert "  " (if (cdr color)
+			    (mapconcat 'identity (cdr color) ", ")
+			  (car color))
+		   "\n"))
+	 (point)
+	 'face (cons 'foreground-color (car color)))))))
+
+(defun list-colors-duplicates (&optional list)
+  "Return a list of colors with grouped duplicate colors.
+If a color has no duplicates, then the element of the returned list
+has the form '(COLOR-NAME).  The element of the returned list with
+duplicate colors has the form '(COLOR-NAME DUPLICATE-COLOR-NAME ...).
+This function uses the predicate `facemenu-color-equal' to compare
+color names.  If the optional argument LIST is non-nil, it should
+be a list of colors to display.  Otherwise, this function uses
+a list of colors that the current display can handle."
+  (let* ((list (mapcar 'list (or list (defined-colors))))
+	 (l list))
+    (while (cdr l)
+      (if (and (facemenu-color-equal (car (car l)) (car (car (cdr l))))
+	       (not (and (boundp 'w32-default-color-map)
+			 (not (assoc (car (car l)) w32-default-color-map)))))
+	  (progn
+	    (setcdr (car l) (cons (car (car (cdr l))) (cdr (car l))))
+	    (setcdr l (cdr (cdr l))))
+	(setq l (cdr l))))
+    list))
 
 (defun facemenu-color-equal (a b)
   "Return t if colors A and B are the same color.
@@ -525,22 +541,6 @@
   (cond ((equal a b) t)
 	((equal (color-values a) (color-values b)))))
 
-(defun facemenu-color-name-equal (a b)
-  "Return t if colors A and B are the same color.
-A and B should be strings naming colors.  These names are
-downcased, stripped of spaces and the string `grey' is turned
-into `gray'.  This accommodates alternative spellings of colors
-found commonly in the list.  It returns nil if the colors differ."
-  (progn
-    (setq a (replace-regexp-in-string "grey" "gray"
-            (replace-regexp-in-string " " ""
-             (downcase a)))
-         b (replace-regexp-in-string "grey" "gray"
-            (replace-regexp-in-string " " ""
-             (downcase b))))
-
-    (equal a b)))
-
 (defun facemenu-add-face (face &optional start end)
   "Add FACE to text between START and END.
 If START is nil or START to END is empty, add FACE to next typed character

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

Re: list-colors-display: display all color names

[Juri Linkov]

It's possible to use #RRGGBB hex color specifications instead of
color names.  One reason to replace a color name with #RRGGBB
is to use slightly modified RGB values than a color has.  But it
might be difficult for users to obtain corresponding hex values.
Also, users might want to find the color name corresponding to
the known RGB value.

All I propose now is to add color hex values to the *Colors* buffer.
I think that placing them at the right window edge would not be
distracting.  For example:

gray                    grey                                   bebebe
light gray              light grey, LightGray, LightGrey       d3d3d3
midnight blue           MidnightBlue                           191970
navy                    navy blue, NavyBlue                    000080
cornflower blue         CornflowerBlue                         6495ed
dark slate blue         DarkSlateBlue                          483d8b
slate blue              SlateBlue                              6a5acd
medium slate blue       MediumSlateBlue                        7b68ee
light slate blue        LightSlateBlue                         8470ff
medium blue             MediumBlue                             0000cd
royal blue              RoyalBlue                              4169e1
blue                    blue                                   0000ff

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

RE: list-colors-display: display all color names

[Drew Adams]

    It's possible to use #RRGGBB hex color specifications instead of
    color names.  One reason to replace a color name with #RRGGBB
    is to use slightly modified RGB values than a color has.

Library doremi-frm.el changes colors incrementally that way:
http://www.emacswiki.org/elisp/doremi-frm.el.

    But it
    might be difficult for users to obtain corresponding hex values.
    Also, users might want to find the color name corresponding to
    the known RGB value.

Library hexrgb.el has functions that convert between decimal and hex RGB
color specs: http://www.emacswiki.org/elisp/hexrgb.el. There are also a
couple useful functions in hexl.el and float.el.

    All I propose now is to add color hex values to the *Colors* buffer.
    I think that placing them at the right window edge would not be
    distracting.

Good idea. It might also be useful to somehow get the hex code for a color
swatch in Customize (e.g. as a tooltip or when you click Show Face).

Re: list-colors-display: display all color names

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Tue, 04 Jan 2005 11:07:55 +0200
> Cc: emacs-devel@gnu.org
> 
> It's possible to use #RRGGBB hex color specifications instead of
> color names.

Actually, where Emacs interprets such color specs, it uses
#RRRRGGGGBBBB (i.e. 16 bits per color).  In other places, it doesn't
care whether you use 1, 2, 3, or 4 hex digits per principal color (it
passes the spec verbatim to X functions).

> it might be difficult for users to obtain corresponding hex values.

How about adding a function color-values-hex, which calls color-values
and then transforms the result into the hex #RGB notation?  Would that
fix this problem?

> Also, users might want to find the color name corresponding to
> the known RGB value.

Is there any reasonably practical way to do that for an arbitrary RGB
triplet?

For more-or-less standard RGB values, the ones listed in
tty-colors.el, doing that is simply a matter of searching the alist
returned by tty-color-alist; if trhat is what you want, does this
justify a new feature?

> All I propose now is to add color hex values to the *Colors* buffer.
> I think that placing them at the right window edge would not be
> distracting.  For example:
> 
> gray                    grey                                   bebebe
> light gray              light grey, LightGray, LightGrey       d3d3d3

First, if we do that, I'd suggest to use #BE12BE34BE56, i.e. prefix
with # and use 4 digits per color.

And second, what do you suggest to display on character terminals?

Re: list-colors-display: display all color names

[Stefan Monnier]

>> Also, users might want to find the color name corresponding to
>> the known RGB value.

> Is there any reasonably practical way to do that for an arbitrary RGB
> triplet?

A guess a function that returns the closest color-name would be good enough.
What that's good for, I don't know.

>> All I propose now is to add color hex values to the *Colors* buffer.
>> I think that placing them at the right window edge would not be
>> distracting.  For example:
>> 
>> gray                    grey                                   bebebe
>> light gray              light grey, LightGray, LightGrey       d3d3d3

> First, if we do that, I'd suggest to use #BE12BE34BE56, i.e. prefix
> with # and use 4 digits per color.

I agree on the `#'.

But since few (if any) system really support more than 8bit per color, it
seems OK to use the #RRGGBB rather than the more verbose #RRRRGGGGBBBB.
After all, that's what people use in practice, in my experience.

> And second, what do you suggest to display on character terminals?

Why would it need to be any different?


        Stefan

Re: list-colors-display: display all color names

[Richard Stallman]

      But it
    might be difficult for users to obtain corresponding hex values.

x-color-values does the hard part.  You just have to convert those
to hex and put them into the right syntax.

    All I propose now is to add color hex values to the *Colors* buffer.

It sounds like a good idea.

    I think that placing them at the right window edge would not be
    distracting.

I agree, but note you'd need to handle the case where the list of
aliases is too long and goes past that column.

Re: list-colors-display: display all color names

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
>> From: Juri Linkov <juri@jurta.org>
>> it might be difficult for users to obtain corresponding hex values.
>
> How about adding a function color-values-hex, which calls color-values
> and then transforms the result into the hex #RGB notation?  Would that
> fix this problem?

A function is not a problem.  A simple piece of code like this

         (apply 'format " #%02x%02x%02x"
                 (mapcar (lambda (c) (lsh c -8)) (color-values color)))

can do that.  Creating a special function with this code will not
fix this problem since users might not be aware of such a function.
Adding #RGB to every color name displayed by `list-colors-display'
in the *Colors* buffer is a more practical solution.

>> Also, users might want to find the color name corresponding to
>> the known RGB value.
>
> For more-or-less standard RGB values, the ones listed in
> tty-colors.el, doing that is simply a matter of searching the alist
> returned by tty-color-alist; if trhat is what you want, does this
> justify a new feature?

RGB values returned by tty-color-alist are represented as integers
0-65535 while the most widespread format for specifying color triplets
is hexadecimal #RRGGBB.

>> gray                    grey                                   bebebe
>> light gray              light grey, LightGray, LightGrey       d3d3d3
>
> First, if we do that, I'd suggest to use #BE12BE34BE56, i.e. prefix
> with # and use 4 digits per color.

4 digits per color?  Why?  The human eye can distinguish no more than about
400,000 colors (some say 10 million colors which is the largest estimation)
and can identify far less colors.  8 bits per color which encodes more
than 16 million colors is completely enough (usually even 600 colors
displayed by `list-colors-display' is enough).  I won't argue about why
Emacs supports so many colors (10^14), but what I want to say is that using
any format longer than #RRGGBB is too impractical.

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

Re: list-colors-display: display all color names

[Juri Linkov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Also, users might want to find the color name corresponding to
>>> the known RGB value.
>
>> Is there any reasonably practical way to do that for an arbitrary RGB
>> triplet?
>
> A guess a function that returns the closest color-name would be good enough.
> What that's good for, I don't know.

There is already such a function: `tty-color-approximate' (currently
it works only for tty colors).  I don't know how it is useful from the
user's POV.  What I intended with adding #RRGGBB values was to make it
easier for users getting somewhere a #RRGGBB value to see if there is
a corresponding easily rememberable color name.

With #RRGGBB values printed in the *Colors* buffer it would be possible
to find closer color names even without a function, simply with a regexp
isearch like M-C-s #f.[fe].e.  It will not find the closest color name,
but it is good enough to help to find all closer colors.

Even better would be if the *Colors* buffer was sorted by RGB values.
I don't suggest to do that by default, but different sorting order would
be useful, e.g. by color name, by color intensity.  The latter is good
for finding a darker or brighter color than a given color, but it is not
so obvious since there are too many variants of projecting a color value
from 3-D color space into a 1-D color list.  Perhaps the most useful is
sorting by hue into a rainbow, and inside every hue sorting by value*saturation.

>>> gray                    grey                                   bebebe
>>> light gray              light grey, LightGray, LightGrey       d3d3d3
>
>> First, if we do that, I'd suggest to use #BE12BE34BE56, i.e. prefix
>> with # and use 4 digits per color.
>
> I agree on the `#'.

I omitted the `#' to save more space.  But OK, one character is not
too much to remind the users about the proper format.

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

RE: list-colors-display: display all color names

[Drew Adams]

    With #RRGGBB values printed in the *Colors* buffer it would be possible
    to find closer color names even without a function, simply with a regexp
    isearch like M-C-s #f.[fe].e.  It will not find the closest color name,
    but it is good enough to help to find all closer colors.

    Even better would be if the *Colors* buffer was sorted by RGB values.
    I don't suggest to do that by default, but different sorting order would
    be useful, e.g. by color name, by color intensity.  The latter is good
    for finding a darker or brighter color than a given color, but it is not
    so obvious since there are too many variants of projecting a color value
    from 3-D color space into a 1-D color list.  Perhaps the most useful is
    sorting by hue into a rainbow, and inside every hue sorting by
    value*saturation.

Great idea. There are usually so many colors in `list-colors-display' that
it is hard to find a "good" ordering - what is good for one user at one time
is different from what it is otherwise.

Being able to sort the colors in different ways would be a definite
improvement.
In terms of a default order, I do think that RGB order would be generally
more useful than color name. The current order is ad hoc, BTW - colors are
currently not sorted by name (the order is implementation-dependent, and is
essentially whatever `xw-defined-colors' returns, which is `w32-color-map'
or `x-colors').

    >>> gray         grey               bebebe
    >>> light gray   light grey, LightGray, LightGrey    d3d3d3
    >> First, if we do that, I'd suggest to use #BE12BE34BE56, i.e. prefix
    >> with # and use 4 digits per color.
    > I agree on the `#'.

    I omitted the `#' to save more space.  But OK, one character is not
    too much to remind the users about the proper format.

The # is important for 1) recognition of what this is about and 2)
copy+pasting to Lisp code or to commands that ask for a color.

RE: list-colors-display: display all color names

[Drew Adams]

    >> it might be difficult for users to obtain corresponding hex values.
    > How about adding a function color-values-hex, which calls color-values
    > and then transforms the result into the hex #RGB notation?  Would that
    > fix this problem?

    A function is not a problem.  A simple piece of code like this
             (apply 'format " #%02x%02x%02x"
                     (mapcar (lambda (c) (lsh c -8)) (color-values color)))
    can do that.  Creating a special function with this code will not
    fix this problem since users might not be aware of such a function.
    Adding #RGB to every color name displayed by `list-colors-display'
    in the *Colors* buffer is a more practical solution.

Adding hex codes to `list-colors-display' is good.
Having functions to convert decimal RGB to hex and vice versa is also good.

    >> gray                    grey                                   bebebe
    >> light gray              light grey, LightGray, LightGrey       d3d3d3
    > First, if we do that, I'd suggest to use #BE12BE34BE56, i.e. prefix
    > with # and use 4 digits per color.

    4 digits per color?  Why?  The human eye can distinguish no
    more than about 400,000 colors (some say 10 million colors
    which is the largest estimation) and can identify far less colors.
    8 bits per color which encodes more than 16 million colors is
    completely enough (usually even 600 colors displayed by
    `list-colors-display' is enough).  I won't argue about why
    Emacs supports so many colors (10^14), but what I want to say
    is that using any format longer than #RRGGBB is too impractical.

Whatever number of digits is needed to represent a given color should be
used in `list-colors-display'. It may be unlikely, but if two available
colors differ only in the 4th red digit, then their displayed hex codes
should reflect that and not appear to be identical - regardless of whether
our eyes can distinguish them. If all available colors happen to fit the
#RRGGBB format, then that will be sufficient, but why shoe-horn all colors
into that format?

In general, regarding Emacs Lisp that manipulates hex RGB codes: Is there a
reason not to treat an _arbitrary_ number (3*n) of hex digits? Or not to use
a variable for the number of digits to be treated? See
http://www.emacswiki.org/elisp/hexrgb.el for food-for-thought examples.

Re: list-colors-display: display all color names

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Juri Linkov <juri@jurta.org>
> Date: Wed, 05 Jan 2005 07:32:52 +0200
> 
> > How about adding a function color-values-hex, which calls color-values
> > and then transforms the result into the hex #RGB notation?  Would that
> > fix this problem?
> 
> A function is not a problem.  A simple piece of code like this
> 
>          (apply 'format " #%02x%02x%02x"
>                  (mapcar (lambda (c) (lsh c -8)) (color-values color)))
> 
> can do that.  Creating a special function with this code will not
> fix this problem since users might not be aware of such a function.

Users might be oblivious to the existence of `list-colors-display' as
well.  This kind of arguments will not lead us anywhere.

Also, we could add more text to the *Colors* buffer telling users
about related facilities.  But I doubt that this is a grave problem.
Someone who wouldn't hesitate to modify colors one bit at a time is
probably a hacker anyway, and hackers could well be expected to look
for related functions.

> Adding #RGB to every color name displayed by `list-colors-display'
> in the *Colors* buffer is a more practical solution.

But it clutters the display and creates a problem with long lines.  So
I think we need a good reason for adding that.

One idea that I like better is to add tooltips to the colors which
show the hex RGB values.  How about this?

> >> Also, users might want to find the color name corresponding to
> >> the known RGB value.
> >
> > For more-or-less standard RGB values, the ones listed in
> > tty-colors.el, doing that is simply a matter of searching the alist
> > returned by tty-color-alist; if trhat is what you want, does this
> > justify a new feature?
> 
> RGB values returned by tty-color-alist are represented as integers
> 0-65535 while the most widespread format for specifying color triplets
> is hexadecimal #RRGGBB.

Sure, but converting to hex is trivial, more or less.

> 4 digits per color?  Why?

So that we could support more than 8 bits per principal color.  Since
X supports that, when tty-colors was written, we anticipated that
someone might use a 12-digit spec on a tty.

> what I want to say is that using any format longer than #RRGGBB is
> too impractical.

What's impractical about it?  You can compute 12 hex digits as
practically as you can 3 or 6.

Re: list-colors-display: display all color names

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Wed, 05 Jan 2005 07:38:28 +0200
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> 
> There is already such a function: `tty-color-approximate' (currently
> it works only for tty colors).

That's because for graphics displays, the same approximation is done
by the C function x_alloc_nearest_color_1.

> I don't know how it is useful from the user's POV.

`tty-color-approximate' is not a user-level function, in general.

> What I intended with adding #RRGGBB values was to make it
> easier for users getting somewhere a #RRGGBB value to see if there is
> a corresponding easily rememberable color name.

How did you think to do that?  I don't think there's a solution for
this problem, since the full set of colors known to the window system
is unknown to Emacs (the colors that are produced by
`list-colors-display' are taken from a partial list that might be only
a tiny fraction of the full list).

> Even better would be if the *Colors* buffer was sorted by RGB values.
> I don't suggest to do that by default, but different sorting order would
> be useful, e.g. by color name, by color intensity.  The latter is good
> for finding a darker or brighter color than a given color, but it is not
> so obvious since there are too many variants of projecting a color value
> from 3-D color space into a 1-D color list.  Perhaps the most useful is
> sorting by hue into a rainbow, and inside every hue sorting by value*saturation.

If we want to add something like that, I'd rather go for a
full-fledged color selection cube, where one can select a color by
moving the mouse pointer, similar to what some X applets let you do.

Re: list-colors-display: display all color names

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Wed, 5 Jan 2005 10:12:36 -0800
> 
> Is there a reason not to treat an _arbitrary_ number (3*n) of hex
> digits?

Unnecessary complication of the Lisp code in tty-colors.el?

Re: list-colors-display: display all color names

[Edward O'Connor]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

 Juri> There is already such a function: `tty-color-approximate' (currently
 Juri> it works only for tty colors).
 [...]
 Juri> I don't know how it is useful from the user's POV.

 Eli> `tty-color-approximate' is not a user-level function, in general.

I found `tty-color-approximate' to be very useful when trying to pick
face foregrounds and backgrounds that would look nice in X and on TTYs
without needing conditional face specs. I'm only one user out of many,
but I did find the function to be quite useful for a user-level task.


Ted

-- 
Edward O'Connor
ted@oconnor.cx

Ense petit placidam sub libertate quietem.

RE: list-colors-display: display all color names

[Drew Adams]

    Also, we could add more text to the *Colors* buffer telling users
    about related facilities.  But I doubt that this is a grave problem.
    Someone who wouldn't hesitate to modify colors one bit at a time is
    probably a hacker anyway, and hackers could well be expected to look
    for related functions.

Only if we don't make it easy to modify colors a little bit at a time will
that remain the domain of hackers only. If we make it _easy_ to modify
colors incrementally (e.g. slightly more red, slightly lighter with no
change in relative RGB...), then anyone "wouldn't hesitate to modify colors
one bit at a time", and more people might be interested in related color
functions.

However, I agree that there is no need for adding text to *Colors* telling
users about such functions. I agree with Juri, however, that the #xxx...
display is a help.

    > Adding #RGB to every color name displayed by `list-colors-display'
    > in the *Colors* buffer is a more practical solution.

    But it clutters the display and creates a problem with long lines.  So
    I think we need a good reason for adding that.
    One idea that I like better is to add tooltips to the colors which
    show the hex RGB values.  How about this?

As I mentioned in an earlier message, users should be able to copy+paste
#xxx... color specs, in addition to color names. Tooltips don't let you do
that.

As far as clutter is concerned, needing to display each of the color-name
synonyms contributes more to clutter than does #xxx... - I think we can
afford the space needed for #xxx.... If things do turn out to be generally
too cluttered, then we could make these display elements user-configurable
(display synonyms or not, display hex codes or not).

Re: list-colors-display: display all color names

[Richard Stallman]

    > gray                    grey                                   bebebe
    > light gray              light grey, LightGray, LightGrey       d3d3d3

    First, if we do that, I'd suggest to use #BE12BE34BE56, i.e. prefix
    with # and use 4 digits per color.

I don't like that idea.  It would be too much clutter and too hard to read.

Re: list-colors-display: display all color names

[Eli Zaretskii]

> From: Edward O'Connor <ted@oconnor.cx>
> Date: Wed, 05 Jan 2005 11:21:37 -0800
> 
>  Eli> `tty-color-approximate' is not a user-level function, in general.
> 
> I found `tty-color-approximate' to be very useful when trying to pick
> face foregrounds and backgrounds that would look nice in X and on TTYs
> without needing conditional face specs.

Which is generally not a user-level issue, IMHO.  Users are supposed
to do this through Customize.  Face colors that look good on many
display types is something that concerns Emacs maintainers.

Re: list-colors-display: display all color names

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Wed, 5 Jan 2005 11:46:41 -0800
> 
>     Also, we could add more text to the *Colors* buffer telling users
>     about related facilities.  But I doubt that this is a grave problem.
>     Someone who wouldn't hesitate to modify colors one bit at a time is
>     probably a hacker anyway, and hackers could well be expected to look
>     for related functions.
> 
> Only if we don't make it easy to modify colors a little bit at a time will
> that remain the domain of hackers only. If we make it _easy_ to modify
> colors incrementally (e.g. slightly more red, slightly lighter with no
> change in relative RGB...), then anyone "wouldn't hesitate to modify colors
> one bit at a time", and more people might be interested in related color
> functions.

I think this has nothing to do with how easy it is to change colors.
I think only hackers and color freaks modify colors one bit at a time.

Re: list-colors-display: display all color names

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
> Users might be oblivious to the existence of `list-colors-display' as
> well.  This kind of arguments will not lead us anywhere.

Recently mention of `list-colors-display' was added to several
places (docstrings, the Emacs manual).  So likely most users will know
about `list-colors-display'.

>> Adding #RGB to every color name displayed by `list-colors-display'
>> in the *Colors* buffer is a more practical solution.
>
> But it clutters the display and creates a problem with long lines.  So
> I think we need a good reason for adding that.

It doesn't clutter the display too much.  As for the problems
with long lines, they are solvable.

> One idea that I like better is to add tooltips to the colors which
> show the hex RGB values.  How about this?

Tooltips is a too restricted tool: can't copy&paste, can't isearch, etc.

>> what I want to say is that using any format longer than #RRGGBB is
>> too impractical.
>
> What's impractical about it?  You can compute 12 hex digits as
> practically as you can 3 or 6.

Impractical because the most widespread format is #RRGGBB which
compactly encodes any of 16-million colors.

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

Re: list-colors-display: display all color names

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     I think that placing them at the right window edge would not be
>     distracting.
>
> I agree, but note you'd need to handle the case where the list of
> aliases is too long and goes past that column.

There is no problem if #RRGGBB goes past that column: isearch still
can find it, and the user can see and copy the text after doing C-e.

What may cause a problem is `with-output-to-temp-buffer' which
displays the buffer only after color names are printed into it.
This makes problematic the use of the value of `window-width'
during inserting the text into the *Colors* buffer.  One solution
is to move the printing the #RRGGBB values at the right window edge
to `temp-buffer-show-hook' where `window-width' returns the right
value for the displayed output window.

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

Re: list-colors-display: display all color names

[Miles Bader]

> > What's impractical about it?  You can compute 12 hex digits as
> > practically as you can 3 or 6.
> 
> Impractical because the most widespread format is #RRGGBB which
> compactly encodes any of 16-million colors.

The 6-digit version is a good default, but that doesn't mean that the
code shouldn't optionally generate other formats when necessary (when
the actual RGB values dictate).  [I have no idea why you used the word
"impractical", it doesn't seem to make any sense in this context --
something is impractical if it's too expensive to be justified by the
benefits, but as was pointed out, it's not at all expensive to
generate other formats, though the benefits may be slight.]

-Miles

Re: list-colors-display: display all color names

[Juri Linkov]

Miles Bader <snogglethorpe@gmail.com> writes:
>> > What's impractical about it?  You can compute 12 hex digits as
>> > practically as you can 3 or 6.
>> 
>> Impractical because the most widespread format is #RRGGBB which
>> compactly encodes any of 16-million colors.
>
> The 6-digit version is a good default, but that doesn't mean that the
> code shouldn't optionally generate other formats when necessary (when
> the actual RGB values dictate).

Yes, longest formats should be generated for colors really encoded
by more than 24 bits.  Is it possible to tell this from the color
value returned by `color-values'?  I noticed that for all 24-bit
colors the 8-bit part in the 16-bit color component value returned
by `color-values' is always duplicated in its highest and lowest
8-bit part, e.g. #121234345656.  Maybe this fact dictates that
the color is 24-bit and can be represented by the shorter format
#123456?

> [I have no idea why you used the word "impractical", it doesn't seem
> to make any sense in this context -- something is impractical if
> it's too expensive to be justified by the benefits, but as was
> pointed out, it's not at all expensive to generate other formats,
> though the benefits may be slight.]

It's expensive in the sense that #RRRRGGGGBBBB consumes more space
than #RRGGBB in the *Colors* buffer, so it can cause long lines
truncated at the right window edge.

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