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

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

[Glenn Morris]

>   color-lab.el: New file.

This needs cl when compiling. (This is flagged by the compiler.)
 

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

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

>>   color-lab.el: New file.
>
> This needs cl when compiling. (This is flagged by the compiler.)

Why is this non-gnus-related library being checked into the Gnus
repository?

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

[Julien Danjou]

On Tue, Nov 23 2010, Chong Yidong wrote:

> Why is this non-gnus-related library being checked into the Gnus
> repository?

Because it is used by Gnus?

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

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

[Julien Danjou]

On Tue, Nov 23 2010, Glenn Morris wrote:

>>   color-lab.el: New file.
>
> This needs cl when compiling. (This is flagged by the compiler.)

I'll try to take a look to remove that, thanks.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

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

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

> Why is this non-gnus-related library being checked into the Gnus
> repository?

It's used by the HTML rendering library used by Gnus.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Chong Yidong]

Julien Danjou <julien@danjou.info> writes:

> On Tue, Nov 23 2010, Chong Yidong wrote:
>
>> Why is this non-gnus-related library being checked into the Gnus
>> repository?
>
> Because it is used by Gnus?

By that logic, we should move all of Emacs into the Gnus tree.  This is
a general purpose library, not specific to Gnus.  It really ought to be
moved out into the Emacs tree.  If no one objects, I'm going to move it.

Also, it is going to have be be fixed.  For example, it violates
function naming conventions---some functions start with `color-lab',
others with `lab', and still others with no prefix at all.  All this
could have been caught if you'd posted the file to emacs-devel and gone
through the usual process of getting a library into the Emacs tree.

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

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

> By that logic, we should move all of Emacs into the Gnus tree.  This is
> a general purpose library, not specific to Gnus.  It really ought to be
> moved out into the Emacs tree.  If no one objects, I'm going to move it.

It is actively being hacked on, and Gnus is the only user.  After it
stabilises then, yes, it should be moved, but not at present.

> Also, it is going to have be be fixed.  For example, it violates
> function naming conventions---some functions start with `color-lab',
> others with `lab', and still others with no prefix at all.  All this
> could have been caught if you'd posted the file to emacs-devel and gone
> through the usual process of getting a library into the Emacs tree.

It's being worked on.  It's brand new code.  Chill out.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Chong Yidong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> By that logic, we should move all of Emacs into the Gnus tree.  This is
>> a general purpose library, not specific to Gnus.  It really ought to be
>> moved out into the Emacs tree.  If no one objects, I'm going to move it.
>
> It is actively being hacked on, and Gnus is the only user.  After it
> stabilises then, yes, it should be moved, but not at present.
>
> It's being worked on.  It's brand new code.  Chill out.

I see.  Why not just use hexrgb.el (or build on it)?  It's been around
long enough that such teething problems should have been eliminated.

Drew Adams has an assignment on file; if he is willing to include
hexrgb.el under that assignment, we could simply add that to Emacs.
Whatever additional functionality you need that isn't already present,
you could then simply add.

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

[Ted Zlatanov]

On Tue, 23 Nov 2010 22:16:51 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Chong Yidong <cyd@stupidchicken.com> writes:
>> Why is this non-gnus-related library being checked into the Gnus
>> repository?

LMI> It's used by the HTML rendering library used by Gnus.

There are others like it, living in the Gnus repo and outside of Gnus in
the Emacs repo (e.g. message.el and imap.el).  We just need Yamaoka-san
to adjust the synchronization scripts to drop color-lab.el into a
different location in the Emacs tree.  I don't know how he does it but
it's not a big deal for other packages like message.el and imap.el IIUC.

Ted

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

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

> I see.  Why not just use hexrgb.el (or build on it)?  It's been around
> long enough that such teething problems should have been eliminated.

The purpose of color-lab is to compute readable colours.

The use case is this:

Given a constant background colour in a buffer, you then have a <p
style="color: blue"> HTML element.  If you have a white background, then
that's fine.  If you have a black background, the blue colour will be
unreadable.  color-lab computes a "distance" between black and a blue
hue that is readable, and that blue hue is used instead.  It's kinda
neat. 

So it doesn't have much to do with hexrgb.el, I think.  Did you read the
code?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Drew Adams]

> I see.  Why not just use hexrgb.el (or build on it)?  It's been around
> long enough that such teething problems should have been eliminated.
> 
> Drew Adams has an assignment on file; if he is willing to include
> hexrgb.el under that assignment, we could simply add that to Emacs.
> Whatever additional functionality you need that isn't already present,
> you could then simply add.

Almost missed this mail - haven't been following this thread.

Yes, you can include hexrgb.el in Emacs if you want.

There is no doubt some overlap between `hexrgb-read-color' in hexrgb.el and
`read-color' in Emacs (originally from hexrgb.el, but modified since).

Someone should take a look, to see if you need to merge/adapt some things (e.g.
in facemenu.el).  Some things like extra defcustom :group's will need to be
removed from the hexrgb.el code.

Some of the hexrgb.el code uses functions and vars from eyedropper.el, but not
in any essential way.  This part lets you use colors that you pick up from under
the cursor or the pointer, as with an eyedrop.

These parts can be cut out of the hexrgb.el code, or you can also include
eyedropper.el in Emacs (it is small).  Some of the eyedropper.el functions have
already been added to Emacs (`face-at-point' is `eyedropper-face-at-point'
etc.).  That's another possibility: add the eyedropper.el code but drop the
prefix `eyedrop-'.

There are two places where the hexgrb.el code is conditional for Emacs 20:

- work around an Emacs 20 bug: (= N N) returns t for a Nan
- use of `try-completion' if `test-completion' is not defined

These are short enough and benign enough that I'd hope they could stay in the
code.

I'm willing to make changes that you request.  If there are no incompatible
changes, so I can also use it for my local needs, then I won't need to also
maintain it separately (locally).  Otherwise (incompatible changes, stuff
removed that I need), then I will either need to also maintain a local version
or move the differences to another local file.  Depends on what changes you
require.

The code is here:
http://www.emacswiki.org/emacs/hexrgb.el
http://www.emacswiki.org/emacs/eyedropper.el

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

[Drew Adams]

> > I see.  Why not just use hexrgb.el (or build on it)?  It's 
> > been around long enough that such teething problems should
> > have been eliminated.
>
> ... 
> color-lab computes a "distance" between black and a blue
> hue that is readable... 
> 
> So it doesn't have much to do with hexrgb.el, I think.

Dunno.

Such a particular color distance computation is I guess complementary to what is
in hexrgb.el.  But in general that is the kind of thing that hexrgb.el does.
For example, `hexrgb-complement' returns the complement of a given color.
Taking the difference between the hue values of two colors gives you a hue
distance, and so on.

That kind of color distance is already there - nothing to be done.  You can
easily combine these kinds of distance in some way - e.g. A * hue-dist + B *
saturation-dist + C * value-dist = my-dist.

You seem to be describing something oriented toward a particular application:
"just distant enough to improve readability" or some such.  It would not be
off-topic for hexrgb to include such a color-distance metric.  I just haven't
needed that so I haven't added it.

If it is decided to include hexrgb.el in Emacs then we could add such a function
to hexrgb.el if the function is fairly general.  Or we could add it elsewhere
(e.g. gnus) and just use hexrgb.el for its definition (or not).

It sounds like the real task for your function is the design: just what kind of
distance function do you want?  You mention "readable", so that could be one
criterion of use.  But the devil might well be in the details (influence of
dark/light backgrounds, human eye characteristics, etc.)

Certainly you can already use hexrgb.el to calculate the distance between two
colors in terms of any color components.  The question is what you want to do
with such a difference: what distance is a good one for something to be
"readable enough", etc.

hexrgb.el has an approximately-equal function that you can use for this kind of
thing (not approximatly equal = sufficiently distant), passing an appropriate
fuzz factor.

For instance, I do something similar in my palette.el code, in order to
determine when a color is essentially the same as its complement.  When that's
the case I change the cursor color to an alternative color that stands out
better against that color as background.

You might look at hexrgb.el to see if you can use the functions there to define
what you need.  Just a suggestion.

In sum, this sounds hexrgb.el-like to me, and I cannot tell whether what you
want is already available using what is in hexrgb.el.

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

[Richard Stallman]

    By that logic, we should move all of Emacs into the Gnus tree.  This is
    a general purpose library, not specific to Gnus.  It really ought to be
    moved out into the Emacs tree.  If no one objects, I'm going to move it.

Hear, hear.

There has been a tendency for all sorts of code unrelated to Gnus to
get installed in Emacs through Gnus.  Some of these things were worth
including in Emacs, but handling them as part of Gnus meant they did
not get properly integrated, properly documented, etc.  I moved some
of them out of Gnus, but I didn't have time to do them all.

It would be really good to start always handling these programs the
right way, by installing them in Emacs outside of Gnus.


-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

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

[Julien Danjou]

On Wed, Nov 24 2010, Drew Adams wrote:

> Dunno.

But you write a lot for someone who do not know. :)

> You seem to be describing something oriented toward a particular application:
> "just distant enough to improve readability" or some such.  It would not be
> off-topic for hexrgb to include such a color-distance metric.  I just haven't
> needed that so I haven't added it.

Color-lab has been built upon a specific need, which resulted in the CIE
Delta E 2000 formula to be implemented. Some helper functions dealing
with colors have been written, like CIE XYZ and CIE Lab conversion in
the process.

All of this is not present in hexrgb, and hexrgb is not present in Emacs.

I admit: color-lab has 50 SLOC for 2 functions (rgb->hsl and rgb->hsv)
which are in hexrgb, but they are even not used at all by the CIE code.

So I think it's really unfair to stand up and point at this package like
it's something that should not have been done.

Now if you want to merge hexrgb and color-lab, why not, but stop
pointing at other people work because some is not included in Emacs.

I can't do anything about it.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

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

[Eli Zaretskii]

> From: Julien Danjou <julien@danjou.info>
> Date: Wed, 24 Nov 2010 10:08:13 +0100
> Cc: 'Lars Magne Ingebrigtsen' <larsi@gnus.org>, emacs-devel@gnu.org
> 
> Color-lab has been built upon a specific need, which resulted in the CIE
> Delta E 2000 formula to be implemented. Some helper functions dealing
> with colors have been written, like CIE XYZ and CIE Lab conversion in
> the process.
> 
> All of this is not present in hexrgb, and hexrgb is not present in Emacs.
> 
> I admit: color-lab has 50 SLOC for 2 functions (rgb->hsl and rgb->hsv)
> which are in hexrgb, but they are even not used at all by the CIE code.
> 
> So I think it's really unfair to stand up and point at this package like
> it's something that should not have been done.
> 
> Now if you want to merge hexrgb and color-lab, why not, but stop
> pointing at other people work because some is not included in Emacs.
> 
> I can't do anything about it.

Perhaps we could all stop being apologetic and pointing fingers at one
another, and see one important lesson to be learned here: that before
adding a package to Emacs, the contributor should talk to the head
maintainers about where the new package should be and whether it
should be a new one or an addition to an existing one.

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

[Stefan Monnier]

> There has been a tendency for all sorts of code unrelated to Gnus to
> get installed in Emacs through Gnus.  Some of these things were worth
> including in Emacs, but handling them as part of Gnus meant they did
> not get properly integrated, properly documented, etc.

I think there is a dual way to look at it: Gnus goes through the trouble
to try and cleanly modularize its code into sub-packages that can be
useful in their own right.

I think it's not very realistic to expect them to first get the package
included in Emacs, since Gnus also supports older Emacsen (as well as
(S)XEmacs).

So, yes, maybe the Gnus maintainers could be more proactive in
discussing new sub-packages with us, but we should also try to be
more understanding.  I really don't think there's ill-will on
either side.


        Stefan

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

[Stefan Monnier]

> Perhaps we could all stop being apologetic and pointing fingers at one
> another, and see one important lesson to be learned here: that before
> adding a package to Emacs, the contributor should talk to the head
> maintainers about where the new package should be and whether it
> should be a new one or an addition to an existing one.

Agreed.  And the other side of the coin is that rather than complain
about a new package that not included the way we want it, we should
welcome the new addition and drool over the synergistic opportunity to
merge it with some other package [yes, maybe I'm pushing it a bit, but
I'm sure you see what I mean].


        Stefan

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

[Lennart Borgman]

On Wed, Nov 24, 2010 at 3:46 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Perhaps we could all stop being apologetic and pointing fingers at one
>> another, and see one important lesson to be learned here: that before
>> adding a package to Emacs, the contributor should talk to the head
>> maintainers about where the new package should be and whether it
>> should be a new one or an addition to an existing one.
>
> Agreed.  And the other side of the coin is that rather than complain
> about a new package that not included the way we want it, we should
> welcome the new addition and drool over the synergistic opportunity to
> merge it with some other package [yes, maybe I'm pushing it a bit, but
> I'm sure you see what I mean].

A problem is of course if gnus is including it to add a new
possibility and that is not yet in Emacs. Maybe GELPA (or whatever it
is called) could be a help in the transition.

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

[Drew Adams]

> > Dunno.
> 
> But you write a lot for someone who do not know. :)

I said I do not know whether color-lab.el "doesn't have much to do with
hexrgb.el" (Lars).  I did not say that I do not know anything.  I wrote about
what I do know about: hexrgb.el.

What did I mean by "dunno" here?  Read what followed "dunno":

d> Dunno.  Such a particular color distance computation is I guess
d> complementary to what is in hexrgb.el.  But in general that is
d> the kind of thing that hexrgb.el does.

So wrt particular content: it seems _complementary_.  But in general, color
difference _is_ the kind of thing that hexrgb.el does.  So yes and no - dunno
based only on Lars's general description of color-lab.el.

> All of this is not present in hexrgb

Complementary.
 
> I admit: color-lab has 50 SLOC for 2 functions (rgb->hsl and rgb->hsv)
> which are in hexrgb, but they are even not used at all by the 
> CIE code.

I already made it clear during the discussion of rainbow-mode.el that such
overlap is to be expected.  These are just standard color conversions.

> So I think it's really unfair to stand up and point at this 
> package like it's something that should not have been done.
> 
> Now if you want to merge hexrgb and color-lab, why not, but stop
> pointing at other people work because some is not included in Emacs.
> 
> I can't do anything about it.

You replied to my mail, but is this directed at me or someone else?  I haven't
pointed at any package as something that should not have been done.  I haven't
pointed at anyone's work because something is not in Emacs (?).  "Really
unfair", indeed.

I simply replied to Yidong's mention of possibly including hexrgb.el (it's OK).

And to Lars's indication that color-lab.el was about calculating a color
distance and that (he thinks) that has little to do with hexrgb.el.  I was going
by what Lars described - I have not looked at color-lab.el myself.

Whether color-lab.el _in fact_ has anything to do with hexrgb.el (e.g. same or
similar subject) I dunno.  And even if it does, whether the two should be
included separately or merged in some way I dunno.  I am not pushing for either
inclusion or merger.  I am not pushing and I am not pointing. ;-)

To be clear, I do not really care whether hexrgb.el, color-lab.el, some
combination of them, or both of them are added to Emacs.  I tried to reply
technically to the question of what hexrgb.el is about.  That's all.

I wrote hexrgb.el for myself and anyone else who wants to use it.  I am glad
that someone wrote color-lab.el as well.  Heuristically determining readable
colors would be useful - I'm glad you're working on it.

Whether any of this stuff should be added to Emacs is another story, and not for
me to decide.

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

[Chong Yidong]

Julien Danjou <julien@danjou.info> writes:

>> You seem to be describing something oriented toward a particular
>> application: "just distant enough to improve readability" or some
>> such.  It would not be off-topic for hexrgb to include such a
>> color-distance metric.  I just haven't needed that so I haven't added
>> it.
>
> Color-lab has been built upon a specific need, which resulted in the
> CIE Delta E 2000 formula to be implemented. Some helper functions
> dealing with colors have been written, like CIE XYZ and CIE Lab
> conversion in the process.

I see; thanks for the explanation, and for writing the CIEDE functions,
and I apologize if I was too gruff in my earlier emails.  But the basic
point stands.  The color-lab.el file describes itself thusly:

   ;; This package provides color manipulation functions.

No mention of CIEDE here, and rightly so; what's needed is a
general-purpose color manipulation library, and CIEDE is only one piece
of such a library.  Such a library does not belong in the Gnus
subdirectory tree.

So, shall we pull the file out into Emacs?  Then we can merge it with
hexrgb.el, and maybe move `read-color' there as well.

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

[Ted Zlatanov]

On Wed, 24 Nov 2010 08:15:25 -0800 "Drew Adams" <drew.adams@oracle.com> wrote: 

DA> Such a particular color distance computation is I guess complementary
DA> to what is in hexrgb.el.  But in general that is the kind of thing
DA> that hexrgb.el does.

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.

On Wed, 24 Nov 2010 11:29:39 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> So, shall we pull the file out into Emacs?  Then we can merge it with
CY> hexrgb.el, and maybe move `read-color' there as well.

I think we should.  It's good core functionality.

Ted

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

[Ted Zlatanov]

On Wed, 24 Nov 2010 16:30:09 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> A problem is of course if gnus is including it to add a new
LB> possibility and that is not yet in Emacs. Maybe GELPA (or whatever
LB> it is called) could be a help in the transition.

I think color-lab.el is too useful to be an external package.  I can see
many areas of Emacs that would benefit from it.  For instance it will
allow for color blindness; setting that as a user preference in one
place would be nice to let all of Emacs adjust color contrasts
appropriately: default colors, themes, color pickers, etc.

Ted

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

[Drew Adams]

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

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

[Julien Danjou]

<#secure method=pgpmime mode=sign>
On Wed, Nov 24 2010, Drew Adams wrote:

> 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).

These 2 functions are not used by any code in color-lab (or Gnus). They
have been merged in because, well, I wrote them so it seemed like a good
idea to no throw them in the trash right.

> 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"?

Since it will end in Emacs, fine with me. I did not choose color.el on
start on Lars advice, since, that name was too generic. But a generic
name for a generic color library in Emacs sounds good. :)

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

I agree.

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

It's already in a separate library called shr-color.el.

> 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.)

It has only (a).

What I can do on my side is:
1. Rename color-lab.el to color.el
2. Merge things other people sends inside, as long as it's basic color
   manipulation related stuff (conversion, etc).

Sounds good?

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

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

[Lennart Borgman]

2010/11/24 Ted Zlatanov <tzz@lifelogs.com>:
> On Wed, 24 Nov 2010 16:30:09 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
> LB> A problem is of course if gnus is including it to add a new
> LB> possibility and that is not yet in Emacs. Maybe GELPA (or whatever
> LB> it is called) could be a help in the transition.
>
> I think color-lab.el is too useful to be an external package.  I can see
> many areas of Emacs that would benefit from it.  For instance it will
> allow for color blindness; setting that as a user preference in one
> place would be nice to let all of Emacs adjust color contrasts
> appropriately: default colors, themes, color pickers, etc.

I did not say it should stay in "GELPA".

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

[Drew Adams]

> Sounds good?

Sounds fine to me.  hexrgb.el is here:
http://www.emacswiki.org/emacs/hexrgb.el.
See my earlier mail for some specific considerations.
Let me know if you have any questions.

Someone will need to decide about the eyedropper stuff.
You can DTRT based on that decision.

Since there are currently no dependencies between the hexrgb stuff and the CIE
stuff, we might want to have two separate sections in the file, separated by,
e.g., `C-q C-l' and a comment.

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

[Lars Magne Ingebrigtsen]

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

> Agreed.  And the other side of the coin is that rather than complain
> about a new package that not included the way we want it, we should
> welcome the new addition and drool over the synergistic opportunity to
> merge it with some other package [yes, maybe I'm pushing it a bit, but
> I'm sure you see what I mean].

I'm wondering whether it may be used in defface.

Gnus now has a gazillion defface declarations like this:

(defface gnus-group-news-2-empty
  '((((class color)
      (background dark))
     (:foreground "turquoise"))
    (((class color)
      (background light))
     (:foreground "CadetBlue4"))
    (t
     ()))

Which is very general and all, but the colours chosen are usually quite
garish, since (for instance) `light' commonly spans the gamut from white
to gray, so we have to choose colours that pop.

We could start choosing more mellifluous hues by default, and have
color-lab ensure that the text would be readable for all users...  That
is, reduce the fruit salad-ey-ness that Emacs has now.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Use color-tweaking code to improve face defaults? [was: /srv/bzr/emacs/trunk r1...]

[Drew Adams]

> Gnus now has a gazillion defface declarations like this:
> 
> (defface gnus-group-news-2-empty
>   '((((class color)(background dark))(:foreground "turquoise"))
>     (((class color)(background light))(:foreground "CadetBlue4"))
>     (t ()))
> 
> Which is very general and all, but the colours chosen are 
> usually quite garish, since (for instance) `light' commonly
> spans the gamut from white to gray, so we have to choose
> colours that pop.
> 
> We could start choosing more mellifluous hues by default, and have
> color-lab ensure that the text would be readable for all users...
> That is, reduce the fruit salad-ey-ness that Emacs has now.

I suggest a separate thread for this.

I personally agree that an ability to tweak colors for human readability etc.
_can_ sometimes help developers come up with better default values for face
colors.

(One might have doubts about "readable for all users", but let's assume that's
feasible.)

However, regardless of which colors you might come up with and propose, for
whichever face defaults, there is bound to be a lively discussion (aka melee).
There are lots of considerations when choosing _default_ colors for faces.

That's no reason not to try or not to discuss.  Just be forewarned to have
pastel expectations. ;-)

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

[Stefan Monnier]

>> Agreed.  And the other side of the coin is that rather than complain
>> about a new package that not included the way we want it, we should
>> welcome the new addition and drool over the synergistic opportunity to
>> merge it with some other package [yes, maybe I'm pushing it a bit, but
>> I'm sure you see what I mean].
> I'm wondering whether it may be used in defface.

Probably, yes.

> We could start choosing more mellifluous hues by default, and have
> color-lab ensure that the text would be readable for all users...  That
> is, reduce the fruit salad-ey-ness that Emacs has now.

That would be wonderful indeed.  Not sure easy that would be (what with
having to take into account limitations such as an 8- or 16-color text
terminal), but it sounds quite intriguing.


        Stefan

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

[Ted Zlatanov]

On Wed, 24 Nov 2010 23:53:52 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> We could start choosing more mellifluous hues by default, and have
>> color-lab ensure that the text would be readable for all users...  That
>> is, reduce the fruit salad-ey-ness that Emacs has now.

SM> That would be wonderful indeed.  Not sure easy that would be (what with
SM> having to take into account limitations such as an 8- or 16-color text
SM> terminal), but it sounds quite intriguing.

Lars' original proposition would be nice, I think, if there was a
facility to convert (using his example)

(defface gnus-group-news-2-empty
  '((((class color)
      (background dark))
     (:foreground "turquoise"))
    (((class color)
      (background light))
     (:foreground "CadetBlue4"))
    (t
     ()))

to

(defface gnus-group-news-2-empty ...)
(color-lab-install-mellifluous-colors 
  'gnus-group-news-2-empty :dark (:foreground "turquoise") :light (:foreground "CadetBlue4"))

;; or...
(color-lab-install-mellifluous-dark-colors  'gnus-group-news-2-empty (:foreground "turquoise"))
(color-lab-install-mellifluous-light-colors 'gnus-group-news-2-empty (:foreground "CadetBlue4"))

Then we can tweak `color-lab-install-mellifluous-colors' to DTRT in all
circumstances, while the package author doesn't have to worry about
those tweaks because his code will work regardless.  In other words,
we'd be switching from a purely data-driven approach with `defface' to a
more flexible declarative approach of `defface' plus color-lab functions.

Ted