From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: /srv/bzr/emacs/trunk r102478: shr.el(shr-tag-color-check):Convert colors to hexadecimal withshr-color->hexadecimal. Date: Wed, 24 Nov 2010 13:00:14 -0800 Message-ID: References: <961v6bom3j.fsf@fencepost.gnu.org> <87eiabdc04.fsf@stupidchicken.com><87ipznhhe3.fsf@keller.adm.naquadah.org><87mxoz7mml.fsf@stupidchicken.com> <874ob71y6v.fsf@stupidchicken.com> <4A76DA00C61D4637AC671E53FB7A4FCB@us.oracle.com><87d3pvf5s2.fsf@keller.adm.naquadah.org> <87d3pu617f.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1290632544 26113 80.91.229.12 (24 Nov 2010 21:02:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 24 Nov 2010 21:02:24 +0000 (UTC) To: "'Ted Zlatanov'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 24 22:02:19 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PLMTq-0005D2-Cm for ged-emacs-devel@m.gmane.org; Wed, 24 Nov 2010 22:02:19 +0100 Original-Received: from localhost ([127.0.0.1]:46812 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PLMTp-0007Pg-W8 for ged-emacs-devel@m.gmane.org; Wed, 24 Nov 2010 16:02:18 -0500 Original-Received: from [140.186.70.92] (port=41037 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PLMTk-0007ON-BD for emacs-devel@gnu.org; Wed, 24 Nov 2010 16:02:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PLMTj-0001Fs-3o for emacs-devel@gnu.org; Wed, 24 Nov 2010 16:02:12 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:47202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PLMTi-0001Fg-T4 for emacs-devel@gnu.org; Wed, 24 Nov 2010 16:02:11 -0500 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oAOL28FH012525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Nov 2010 21:02:09 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oANKIA9C025789; Wed, 24 Nov 2010 21:02:07 GMT Original-Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 811438081290632413; Wed, 24 Nov 2010 13:00:13 -0800 Original-Received: from dradamslap1 (/10.159.223.110) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Nov 2010 13:00:12 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87d3pu617f.fsf@lifelogs.com> Thread-Index: AcuMA0DKQwA9K+8ATiaZt0qQl+ydIQADp4SA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133125 Archived-At: > 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.