[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: color.el
From: |
Chong Yidong |
Subject: |
Re: color.el |
Date: |
Sat, 19 Feb 2011 13:33:08 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
"Drew Adams" <address@hidden> writes:
> I thought that `hexrgb.el' and `color-lab.el' were going to be merged.
>
> I've merged the two libraries now, moved `read-color' to it, and
> cleaned things up (e.g. doc). When there was overlap I kept the best
> version (e.g. most precise or most general). I did not include
> anything from `eyedropper.el' (e.g. for `read-color').
Thanks. I'll start applying some parts of the patch shortly, but here
are a few points worth discussing:
1. Renaming color-rgb->hsv to color-rgb-to-hsv, etc.
The latter is a bit more in line with other Emacs Lisp function
names, though we do have a few named "X->Y".
Any thoughts from Emacs developers? I am not sure myself.
2. Returning HUE in [0,1], rather than radians, by default.
If we do this, I'd rather not add a separate *-radians function; we
should just decide on whether Emacs should represent hue as [0,1], as
radians, or as [0,360], and use that everywhere.
For what it's worth, the Gimp, the Java color library, and the
Eclipse API all use [0,360]. Maybe we should do follow suit. Any
objections?
3. The functions for incrementing color components don't look very
useful to me. Surely it's simple enough for a Lisp program to
increment a member of a list. Is there any real world example of a
program using this part of hexrgb?
- color.el, Drew Adams, 2011/02/16
- Re: color.el,
Chong Yidong <=