Re: color.el

[Miles Bader <miles@gnu.org>]

"Drew Adams" <drew.adams@oracle.com> writes:
>> Radians seem cleaner; an argument range of 0-360 only seems 
>> useful if an interface is primarily user-level (e.g. a spec
>> in a web page or something).
>
> Cleaner than what?  than [0,360]?  than [0,1]?  than both?
> And why?  In particular, why would [0,2*pi] be cleaner than [0,1]?

Actually I was just comparing to 0-360; I agree that 0-1 is probably the
best of them all.

[A possible exception might be if you're trying very hard to avoid
consing; then maybe any use of floats is undesirable.  It doesn't seem
that's considered an issue with this API tho...]

> I agree (if you are saying this) that the input and return values of these
> functions should not assume only or even primarily user-level use cases (e.g.
> web-page color spec).  They should be general functions.  This is essentially a
> utility library of building-block functions.

Agree.

> IMO, the values should be of the same type (a) for all components (r,g,b,h,s,v),
> and (b) for both input and return values.  We should not be sometimes passing in
> [0,1] for RGB and other times passing in [0,255] for RGB.  Similarly for return
> values.  And we should not use [0,360] for H but [0,1] for S and V.

I agree.  

I'd rather not ever use 0-255 in the interface though.  _If_ it's
sometimes desirable to use integers instead of floats for color
components, 0-65535 gives higher resolution, is already in use by Emacs
color functions (`color-values'), and can be efficiently (without
division) converted to 0-255 internally when that range is desirable
(for backends or whatever).

-Miles

-- 
  Dinanzi a me non fuor cose create
se non etterne, e io etterno duro.
Lasciate ogne speranza, voi ch'intrate.