RE: /srv/bzr/emacs/trunk r102478: shr.el(shr-tag-color-check):Convert colors to hexadecimal withshr-color->hexadecimal.

["Drew Adams" <drew.adams@oracle.com>]

> I also think the two should be merged.  Since color-lab.el is a better
> name IMO, could you and Julien merge hexrgb.el into it?  That would
> require work, obviously, but I think it's well worthwhile.  I 
> will help if necessary.

It sounds like there is no overlap, except for two functions (no, I have not
checked, but others seem to have).  I suggest the following steps, if Yidong
etc. agree:

1. Change any calls of those two functions to use the corresponding hexrgb.el
functions instead.  Then test the color-lab use (the two versions might not be
exactly equivalent, even if they do essentially the same thing).

2. Since there is apparently no other overlap, put all of the code from the two
libraries into a single file.

3. Choose a new file name and fix the name prefixes accordingly. "hexrgb" is
probably not general enough (it is not even general enough for all that it does
now, since the name reflects only RGB, not HSV).  I don't think "color-lab" is a
good name for this general library either; this is not just about CIELAB.

How about just "color.el"?

4. Integrate with Emacs.  This involves adjusting/removing any overlapping
existing stuff - e.g. `read-color' and possibly some facemenu stuff.

However, it is possible that someone might prefer that all of this functionality
not be in the same file.  Some hexrgb.el stuff has already been added to Emacs,
and in different places if I'm not mistaken.  Someone apparently thought it was
a good idea to spread such stuff around.

IOW, someone needs to decide whether all of these functions belong in a library,
and if so whether the functions and vars should have a prefix (e.g.
`foo-read-color' vs `read-color').  And in any case any existing functions that
do the same thing or similar should be removed from Emacs (or merged).

Yidong might want to do #4, since it involves some deciding and he is familiar
with the Emacs `read-color' code and recent changes.


A question I have (no, I still have not looked at color-lab.el; I don't even
know where to find it):

Why not merge only the parts of color-lab.el that involve color manipulations
with hexrgb.el, and keep the rest (e.g. heuristics about readability and
color-blindness, color-vision profiles, HTML use etc.) in a separate Emacs
library?

IOW, _if_ color-lab.el has both (a) general color-manipulation/conversion
functions and (b) application-specific functions that use those general
functions, then wouldn't it make sense to keep the latter separate?  (No, I
don't care - it's just a question.)

I would think that we'd want to keep the merged color-manipulation library for
_only_ color manipulation (and possibly the read-color command).

Otherwise, there is a risk that anything at all having to do with some
particular use of color will get stuffed into it.  It's a slippery slope, once
we start allowing in some applications of color.

From the sound of it, part of color-lab.el (CIE etc.) defines color utility
functions, and part of it uses those functions for particular applications.  In
my code, I separate the the color-manipulation library (hexrgb.el) from its
users (palette.el, eyedrop.el, Icicles, DoReMi).  Doesn't that make sense here
too?

Finally, see my previous mail about other changes and decisions that will be
required in order to include the hexrgb.el code.  E.g., Include eyedrop.el?  If
so, add its code to the new color library or keep it separate?  If not,
hexrgb.el will need to be purged of its few calls to the eyedrop functions.

Reminder: Eyedropper just lets you pick up a foreground or background color at
point or under the mouse pointer.  It can save these colors in two global vars
(foreground, background), which can then be used elsewhere. E.g., hexrgb.el uses
them as color candidates for `hexrgb-read-color'.  This means that you do not
need to know what a color is (its name or its RGB or other components) in order
to use it.

HTH.