From drew.adams@oracle.com Tue Aug 4 09:01:39 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 4 Aug 2009 16:01:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,FOURLA,MURPHY_WRONG_WORD1, MURPHY_WRONG_WORD2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74G1Y0k022759 for ; Tue, 4 Aug 2009 09:01:36 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MYMSD-0007WY-Dt for bug-gnu-emacs@gnu.org; Tue, 04 Aug 2009 12:01:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MYMS7-0007Rx-R2 for bug-gnu-emacs@gnu.org; Tue, 04 Aug 2009 12:01:32 -0400 Received: from [199.232.76.173] (port=42280 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MYMS7-0007Rn-CK for bug-gnu-emacs@gnu.org; Tue, 04 Aug 2009 12:01:27 -0400 Received: from rcsinet11.oracle.com ([148.87.113.123]:49361 helo=rgminet11.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MYMS6-0003a6-PX for bug-gnu-emacs@gnu.org; Tue, 04 Aug 2009 12:01:27 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74G2Qfw029550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 Aug 2009 16:02:28 GMT Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74G1jCW017483 for ; Tue, 4 Aug 2009 16:01:45 GMT Received: from dradamslap1 (/141.144.160.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Aug 2009 09:01:21 -0700 From: "Drew Adams" To: Subject: 23.1; list-colors-display is misleading Date: Tue, 4 Aug 2009 09:01:21 -0700 Message-ID: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoVHM9/g5ZCfPigSYaX05zqjrmTPQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010207.4A785B52.0040:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) emacs -Q M-x list-colors-display The RGB values listed at the right side are misleading. I have had at least one user state that he thought that, since the form shown is #RRGGBB, his colors had only that granularity. IOW, even if one's system allows colors of the form #RRRRGGGGBBBB (more colors), the color names are translated to hex strings of the form #RRGGBB (fewer colors). The displayed RGB hex string ideally should reflect the user's actual color possibilities. If there is no way for Emacs to know that, then it's better to err on the side of providing more information: #RRRRGGGGBBBB, rather than less: #RRGGBB. E.g., it's better to translate LightBlue as #befded5effff than as #beedff. And if the user's real color space cannot be known, then a note/legend should be added (at least in the `C-h m' help for the `list-colors-display' buffer, but preferably at the top or bottom of the buffer itself), saying that the RGB code shown is not necessarily representative of the color granularity for your system. In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-29 on SOFT-MJASON Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4)' From eliz@gnu.org Tue Aug 4 11:05:13 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 18:05:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.7 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout6.012.net.il (mtaout6.012.net.il [84.95.2.16]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74I56FO001788 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 11:05:07 -0700 Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KNV00G00643NC00@i-mtaout6.012.net.il> for 4033@emacsbugs.donarmstrong.com; Tue, 04 Aug 2009 21:04:36 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.149.138]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KNV00EG267NXB10@i-mtaout6.012.net.il>; Tue, 04 Aug 2009 21:04:36 +0300 (IDT) Date: Tue, 04 Aug 2009 21:04:35 +0300 From: Eli Zaretskii Subject: Re: bug#4033: 23.1; list-colors-display is misleading In-reply-to: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams , 4033@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: <83r5vro3po.fsf@gnu.org> References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> > From: "Drew Adams" > Date: Tue, 4 Aug 2009 09:01:21 -0700 > Cc: > > emacs -Q > M-x list-colors-display > > The RGB values listed at the right side are misleading. Only if you interpret them to mean not what they were supposed to mean. > The displayed RGB hex string ideally should reflect the user's actual > color possibilities. If there is no way for Emacs to know that, then > it's better to err on the side of providing more information: > #RRRRGGGGBBBB, rather than less: #RRGGBB. E.g., it's better to > translate LightBlue as #befded5effff than as #beedff. 16-bit RGB components is what Emacs uses internally, IIRC. That is the reason we show each one as two letters. I think this bug should be closed. From drew.adams@oracle.com Tue Aug 4 11:49:02 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 18:49:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74Imuxx006081 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 11:48:58 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74ImmGJ024725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Aug 2009 18:48:49 GMT Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74InCZ8015693; Tue, 4 Aug 2009 18:49:12 GMT Received: from dradamslap1 (/141.144.160.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Aug 2009 11:48:47 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" , <4033@debbugs.gnu.org> References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> Subject: RE: bug#4033: 23.1; list-colors-display is misleading Date: Tue, 4 Aug 2009 11:48:49 -0700 Message-ID: <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83r5vro3po.fsf@gnu.org> Thread-Index: AcoVLiLM2ZvXR/nuS7CMt0Iuc8lFQQAAByMQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt001.oracle.com [141.146.116.10] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010208.4A788290.01EE:SCFSTAT5015188,ss=1,fgs=0 > > The RGB values listed at the right side are misleading. > > Only if you interpret them to mean not what they were supposed to > mean. > > > The displayed RGB hex string ideally should reflect the > > user's actual color possibilities. If there is no way for > > Emacs to know that, then it's better to err on the side of > > providing more information: #RRRRGGGGBBBB, rather than less: > > #RRGGBB. E.g., it's better to translate LightBlue as > > #befded5effff than as #beedff. (I meant #ADADD8D8E6E6 and #ADD8E6 for LightBlue - got my numbers wrong; sorry.) > 16-bit RGB components is what Emacs uses internally, IIRC. That is > the reason we show each one as two letters. Is that right? Could you please check about this? I was under the (perhaps mistaken) impression that Emacs treats colors differently, depending on your display's color support. In particular, I thought that `display-color-cells' would show how many colors are supported, and therefore how many RGB hex digits would be appropriate (available) for a given display. IOW, I thought that on some displays you might be able to use only #RRGGBB, while on others you could use #RRRGGGBBB (where there would be a perceived difference when using fewer or more digits). > I think this bug should be closed. If you're sure about what you say, then yes. But please check to be sure. Thx. From drew.adams@oracle.com Tue Aug 4 12:40:54 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 19:40:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74JemYH011251 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 12:40:49 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74JeVpJ026341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Aug 2009 19:40:32 GMT Received: from abhmt005.oracle.com (abhmt005.oracle.com [141.146.116.14]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74JesAa029128; Tue, 4 Aug 2009 19:40:55 GMT Received: from dradamslap1 (/141.144.160.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Aug 2009 12:40:30 -0700 From: "Drew Adams" To: <4033@debbugs.gnu.org>, "'Eli Zaretskii'" References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com><83r5vro3po.fsf@gnu.org> <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> Subject: RE: bug#4033: 23.1; list-colors-display is misleading Date: Tue, 4 Aug 2009 12:40:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> Thread-Index: AcoVLiLM2ZvXR/nuS7CMt0Iuc8lFQQAAByMQAAMk9eA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt005.oracle.com [141.146.116.14] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010202.4A788EAF.0144:SCFSTAT5015188,ss=1,fgs=0 > > > The RGB values listed at the right side are misleading. > > > > Only if you interpret them to mean not what they were supposed to > > mean. > > > > > The displayed RGB hex string ideally should reflect the > > > user's actual color possibilities. If there is no way for > > > Emacs to know that, then it's better to err on the side of > > > providing more information: #RRRRGGGGBBBB, rather than less: > > > #RRGGBB. E.g., it's better to translate LightBlue as > > > #befded5effff than as #beedff. > > (I meant #ADADD8D8E6E6 and #ADD8E6 for LightBlue - got my > numbers wrong; sorry.) > > > 16-bit RGB components is what Emacs uses internally, IIRC. That is > > the reason we show each one as two letters. > > Is that right? Could you please check about this? > > I was under the (perhaps mistaken) impression that Emacs treats colors > differently, depending on your display's color support. In > particular, I thought > that `display-color-cells' would show how many colors are > supported, and > therefore how many RGB hex digits would be appropriate > (available) for a given > display. IOW, I thought that on some displays you might be > able to use only > #RRGGBB, while on others you could use #RRRGGGBBB (where > there would be a > perceived difference when using fewer or more digits). > > > I think this bug should be closed. > > If you're sure about what you say, then yes. But please check > to be sure. Thx. BTW, if what you say is the case, then it is all the more unfortunate, since `color-values' returns values up to 65535 (or 65280, for some platforms). That's 16 ** 4, which means that each color component can be represented by up to 4 hex digits: #RRRRGGGGBBBB. That's one reason I've always assumed that up to 4 hex digits were handled by Emacs. If what you say is true, then what is the reason for such a limitation? Is there some inherent limitation, or is this just a design or implementation bug, which could be fixed? From eliz@gnu.org Tue Aug 4 12:45:43 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 19:45:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout1.012.net.il (mtaout1.012.net.il [84.95.2.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74Jjc1P011633 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 12:45:39 -0700 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KNV00K00AMJMR00@i-mtaout1.012.net.il> for 4033@emacsbugs.donarmstrong.com; Tue, 04 Aug 2009 22:45:31 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.149.138]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KNV00BF9AVO2Q20@i-mtaout1.012.net.il>; Tue, 04 Aug 2009 22:45:25 +0300 (IDT) Date: Tue, 04 Aug 2009 22:45:24 +0300 From: Eli Zaretskii Subject: Re: bug#4033: 23.1; list-colors-display is misleading In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Cc: 4033@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: <83ljlznz1n.fsf@gnu.org> References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> > From: "Drew Adams" > Date: Tue, 4 Aug 2009 12:40:32 -0700 > > BTW, if what you say is the case, then it is all the more unfortunate, since > `color-values' returns values up to 65535 (or 65280, for some platforms). That's > 16 ** 4, which means that each color component can be represented by up to 4 hex > digits: #RRRRGGGGBBBB. That's one reason I've always assumed that up to 4 hex > digits were handled by Emacs. Maybe it's too late and my brain is already asleep, but isn't 65535 2^16-1, i.e. the largest 16-bit number? From drew.adams@oracle.com Tue Aug 4 12:59:12 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 19:59:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74Jx9Yp012523 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 12:59:10 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74Jwb0T014068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Aug 2009 19:58:38 GMT Received: from abhmt013.oracle.com (abhmt013.oracle.com [141.146.116.22]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74Jx0PQ014403; Tue, 4 Aug 2009 19:59:01 GMT Received: from dradamslap1 (/141.144.160.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Aug 2009 12:58:58 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" Cc: <4033@debbugs.gnu.org> References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> <83ljlznz1n.fsf@gnu.org> Subject: RE: bug#4033: 23.1; list-colors-display is misleading Date: Tue, 4 Aug 2009 12:58:59 -0700 Message-ID: <5AC3B6D3FF8F4A9785E27250474FEE3B@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83ljlznz1n.fsf@gnu.org> Thread-Index: AcoVPDhI9hhpUyfiToG1dTJGoNtpsgAAQ+qw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt013.oracle.com [141.146.116.22] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4A789303.0190:SCFSTAT5015188,ss=1,fgs=0 > > BTW, if what you say is the case, then it is all the more > > unfortunate, since `color-values' returns values up to > > 65535 (or 65280, for some platforms). That's > > 16 ** 4, which means that each color component can be > > represented by up to 4 hex digits: #RRRRGGGGBBBB. > > That's one reason I've always assumed that up to 4 hex > > digits were handled by Emacs. > > Maybe it's too late and my brain is already asleep, but isn't 65535 > 2^16-1, i.e. the largest 16-bit number? I might be asleep too, though it's not late here. ;-) Yes, 65535 is 2^16 - 1. And it is also 16^4 - 1. 16^4 means four hex digits. FFFF is 65535. So if we have color values from 0 to 65535 inclusive, then we ought to be able to treat hex codes from 0000 to FFFF also. Four hex digits for each color component: R, G, and B. From juri@jurta.org Tue Aug 4 14:59:44 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 21:59:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL6,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out1.starman.ee [85.253.0.3]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74LxdkT023712 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 14:59:41 -0700 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.70.102.cable.starman.ee [82.131.70.102]) by mx1.starman.ee (Postfix) with ESMTP id 8A3693F419A; Wed, 5 Aug 2009 00:59:33 +0300 (EEST) From: Juri Linkov To: Drew Adams Cc: 4033@debbugs.gnu.org Subject: Re: bug#4033: 23.1; list-colors-display is misleading Organization: JURTA References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> Date: Wed, 05 Aug 2009 00:35:12 +0300 In-Reply-To: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> (Drew Adams's message of "Tue, 4 Aug 2009 09:01:21 -0700") Message-ID: <87ws5j9rcv.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > I have had at least one user state that he thought that, since the > form shown is #RRGGBB, his colors had only that granularity. IOW, > even if one's system allows colors of the form #RRRRGGGGBBBB (more > colors), the color names are translated to hex strings of the form > #RRGGBB (fewer colors). Could you show a formula that calculates the color granularity? We could use it to print colors in the short format #RRGGBB for the smaller color space and #RRRRGGGGBBBB otherwise. -- Juri Linkov http://www.jurta.org/emacs/ From jasonrumney@gmail.com Tue Aug 4 15:59:48 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 22:59:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74Mxi15029155 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 15:59:45 -0700 Received: by wa-out-1112.google.com with SMTP id m28so668251wag.1 for <4033@emacsbugs.donarmstrong.com>; Tue, 04 Aug 2009 15:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:message-id :date:from:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=a3flI0LCPGaobyGA2ZfRQgIAoDl6wPskuMMvbK94w9U=; b=eS0GCo02146uwWrDPv58fAyOgG51OsqrwPl9zQkMhxBPnCweeutEynoETf0g1K4cvV cEDNFKZX7j6k9UOrJHJPPlvoVc1+G1IJ8vNcdNe00GmIWGqLk1c4VTF4mcSPwL57/12W NIjdlWHAe+wjwYbMxt687zT8hFD9/KWsQ7ePU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Pd2sg6KB2YHYtF+KTDp+vR68eqq7pyyBZ0+xLcxNcMpanspJvW4iDVSVfn9NrzbUGo l5tkh2jXfpyl4xttxrOzDdq6f6madlvArFykIKBGUDDaYV4vL9YWqU/xxlfoTYNVj48r nZO2J1iLY5dvNv0lyO59kOvtogVdGPm1P4I+U= Received: by 10.115.18.16 with SMTP id v16mr6984740wai.123.1249426783801; Tue, 04 Aug 2009 15:59:43 -0700 (PDT) Received: from wanchan.jasonrumney.net ([118.101.136.103]) by mx.google.com with ESMTPS id l30sm1206844waf.35.2009.08.04.15.59.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 15:59:43 -0700 (PDT) Sender: Jason Rumney Received: from wanchan.jasonrumney.net (localhost [127.0.0.1]) by wanchan.jasonrumney.net (Postfix) with ESMTP id 7028E784; Wed, 5 Aug 2009 06:59:39 +0800 (MYT) Message-ID: <4A78BD5A.8040901@gnu.org> Date: Wed, 05 Aug 2009 06:59:38 +0800 From: Jason Rumney User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Drew Adams , 4033@debbugs.gnu.org CC: "'Eli Zaretskii'" Subject: Re: bug#4033: 23.1; list-colors-display is misleading References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> In-Reply-To: <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Drew Adams wrote: >> 16-bit RGB components is what Emacs uses internally, IIRC. That is >> the reason we show each one as two letters. >> > > Is that right? Could you please check about this? > Emacs uses 16 bit components internally, because that is what X uses in its APIs. I'm not aware of any graphics driver that allows more than 8 bit granularity though, and on Windows you are restricted to 8 bit by the API anyway. From whitebox@nefkom.net Tue Aug 4 16:27:26 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 23:27:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74NRLPo032207 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 16:27:22 -0700 Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 5D8A71C15370; Wed, 5 Aug 2009 01:27:15 +0200 (CEST) Received: from localhost (dynscan2.mnet-online.de [192.168.1.215]) by mail.m-online.net (Postfix) with ESMTP id 0C9DF901F5; Wed, 5 Aug 2009 01:27:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.3.149]) by localhost (dynscan2.mnet-online.de [192.168.1.215]) (amavisd-new, port 10024) with ESMTP id PpwqCog4atqf; Wed, 5 Aug 2009 01:27:14 +0200 (CEST) Received: from igel.home (DSL01.83.171.165.130.ip-pool.NEFkom.net [83.171.165.130]) by mail.mnet-online.de (Postfix) with ESMTP; Wed, 5 Aug 2009 01:27:14 +0200 (CEST) Received: by igel.home (Postfix, from userid 501) id BE03D10C0FF; Wed, 5 Aug 2009 01:27:13 +0200 (CEST) From: Andreas Schwab To: Eli Zaretskii Cc: 4033@debbugs.gnu.org, Drew Adams Subject: Re: bug#4033: 23.1; list-colors-display is misleading References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> X-Yow: This is PLEASANT! Date: Wed, 05 Aug 2009 01:27:13 +0200 In-Reply-To: <83r5vro3po.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 04 Aug 2009 21:04:35 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Eli Zaretskii writes: > 16-bit RGB components is what Emacs uses internally, IIRC. That is > the reason we show each one as two letters. 16-bit components would require 4 letters. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From drew.adams@oracle.com Tue Aug 4 16:30:09 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 23:30:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_DRUGS_REL6,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74NU4Le032228 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 16:30:06 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74NTu2B018386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Aug 2009 23:29:57 GMT Received: from abhmt016.oracle.com (abhmt016.oracle.com [141.146.116.25]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74NTwNt032704; Tue, 4 Aug 2009 23:29:58 GMT Received: from dradamslap1 (/141.144.224.78) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Aug 2009 16:29:56 -0700 From: "Drew Adams" To: "'Juri Linkov'" Cc: <4033@debbugs.gnu.org> References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <87ws5j9rcv.fsf@mail.jurta.org> Subject: RE: bug#4033: 23.1; list-colors-display is misleading Date: Tue, 4 Aug 2009 16:29:53 -0700 Message-ID: <9FFA12BB16C74D6F91CB6550EA76B86A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoVTuZdnXz2o85zRHy9QT9NRbdW0AAAhN9Q In-Reply-To: <87ws5j9rcv.fsf@mail.jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt016.oracle.com [141.146.116.25] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010204.4A78C475.0064:SCFSTAT5015188,ss=1,fgs=0 > > I have had at least one user state that he thought that, since the > > form shown is #RRGGBB, his colors had only that granularity. IOW, > > even if one's system allows colors of the form #RRRRGGGGBBBB (more > > colors), the color names are translated to hex strings of the form > > #RRGGBB (fewer colors). > > Could you show a formula that calculates the color granularity? > > We could use it to print colors in the short format #RRGGBB > for the smaller color space and #RRRRGGGGBBBB otherwise. Dunno. I'm really no expert on this. But IIUC `display-color-cells' gives info about the color depth / number of colors supported by the display. I was assuming that whatever the display supports Emacs would support too, but maybe that's a mistaken assumption. So I was assuming that `display-color-cells' would indicate the number of colors available (supported). Then, based on that I figured we should be able to know how many hex digits to use for each component. Maybe I'm wrong (it's beginning to sound like it), but that's how I was thinking. Again, I know nothing about this stuff. It's quite likely I'm confusing apples and oranges. Thanks to whoever clarifies this for me. From drew.adams@oracle.com Tue Aug 4 16:30:12 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 23:30:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74NU7BT032267 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 16:30:08 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74NUoo0007165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Aug 2009 23:30:52 GMT Received: from abhmt016.oracle.com (abhmt016.oracle.com [141.146.116.25]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74NULxb024649; Tue, 4 Aug 2009 23:30:22 GMT Received: from dradamslap1 (/141.144.224.78) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Aug 2009 16:29:57 -0700 From: "Drew Adams" To: "'Jason Rumney'" , <4033@debbugs.gnu.org> Cc: "'Eli Zaretskii'" References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> <4A78BD5A.8040901@gnu.org> Subject: RE: bug#4033: 23.1; list-colors-display is misleading Date: Tue, 4 Aug 2009 16:29:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoVV0lT33nZ8QZoSh2xsFUewJIMcgAAIWuA In-Reply-To: <4A78BD5A.8040901@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt016.oracle.com [141.146.116.25] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010203.4A78C476.005A:SCFSTAT5015188,ss=1,fgs=0 > >> 16-bit RGB components is what Emacs uses internally, IIRC. That is > >> the reason we show each one as two letters. > > > > Is that right? Could you please check about this? > > Emacs uses 16 bit components internally, because that is what > X uses in its APIs. I'm not aware of any graphics driver that allows > more than 8 bit granularity though, and on Windows you are restricted > to 8 bit by the API anyway. I'm ignorant about these things. Does that imply that Emacs does not support #RRRRGGGGBBBB (or #RRRGGGBBB) on any systems? What is the relation between these two Doesn't 16-bits per component mean 4 hex digits per component? IOW, #RRRRGGGGBBBB (internally). See my reply to Juri. I'd be grateful for clarification. What's the point of having `display-color-cells' tell me that I have, say 16777216 colors available, if that's not really the case as far as Emacs is concerned? Consider me mixed up about this, and please set me straight. Thx. From jasonrumney@gmail.com Tue Aug 4 16:43:24 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 23:43:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74NhJmG000927 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 16:43:20 -0700 Received: by rv-out-0506.google.com with SMTP id f6so1327986rvb.1 for <4033@emacsbugs.donarmstrong.com>; Tue, 04 Aug 2009 16:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2mRihKyuD2/p7rfdDtkZsoLNEDjh+iqLtO4711XQJrw=; b=UOWYVAnaiPm8D/EhPL5Gl6ncSU3y9ne3t0Y9KfhRx9qHYQa4iC1gzkC4QSzqUxF53S BDgRcencbXqn6nNuUBqFRtKDeNTpEJtmAJBc5qo12upNxloPJtdlCFdtjTtI4OuiY0Km HyqQ8ENUqPyJUV98BierNbKIJnieVSC7MnAcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=RL2Q5NhTMUxmdD7nd138NuhrjTRBreGHmzk2hT8J5cdh+dzhO81hl/fjagR8hkEW3T 0KtbqvVvuDaIC1m0BFkLSOyF+u2j3PKFd+YyweuznUdYYTquyAdZ+nLgTiiDKPI/SM5g Hwba7+DVcy0NXxW5iTwq72yte3qy8jjhsxp/Y= Received: by 10.140.174.20 with SMTP id w20mr2187663rve.63.1249429399289; Tue, 04 Aug 2009 16:43:19 -0700 (PDT) Received: from ?10.1.1.112? ([61.4.103.130]) by mx.google.com with ESMTPS id k37sm4780648rvb.12.2009.08.04.16.43.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 16:43:18 -0700 (PDT) Sender: Jason Rumney Message-ID: <4A78C76C.7010001@gnu.org> Date: Wed, 05 Aug 2009 07:42:36 +0800 From: Jason Rumney User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Drew Adams CC: 4033@debbugs.gnu.org, "'Eli Zaretskii'" Subject: Re: bug#4033: 23.1; list-colors-display is misleading References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> <4A78BD5A.8040901@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Drew Adams wrote: > See my reply to Juri. I'd be grateful for clarification. What's the point of > having `display-color-cells' tell me that I have, say 16777216 colors available, > if that's not really the case as far as Emacs is concerned? > 16777216 = 2^24 = 2^(3*8): #RRGGBB From drew.adams@oracle.com Tue Aug 4 16:56:01 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 4 Aug 2009 23:56:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74NtvlE002090 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 16:55:58 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74Nue8p008142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Aug 2009 23:56:41 GMT Received: from abhmt005.oracle.com (abhmt005.oracle.com [141.146.116.14]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n74NuCsC030712; Tue, 4 Aug 2009 23:56:12 GMT Received: from dradamslap1 (/141.144.224.78) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Aug 2009 16:55:47 -0700 From: "Drew Adams" To: "'Jason Rumney'" Cc: <4033@debbugs.gnu.org>, "'Eli Zaretskii'" References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> <4A78BD5A.8040901@gnu.org> <4A78C76C.7010001@gnu.org> Subject: RE: bug#4033: 23.1; list-colors-display is misleading Date: Tue, 4 Aug 2009 16:55:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoVXYkcjQPgPIPQSm+RQqKUscN9uQAAOaRQ In-Reply-To: <4A78C76C.7010001@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt005.oracle.com [141.146.116.14] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010205.4A78CA84.0085:SCFSTAT5015188,ss=1,fgs=0 > > See my reply to Juri. I'd be grateful for clarification. > > What's the point of having `display-color-cells' tell me > > that I have, say 16777216 colors available, > > if that's not really the case as far as Emacs is concerned? > > 16777216 = 2^24 = 2^(3*8): #RRGGBB = 16^6: 6 hex digits, yes. OK, so that says that my display only handles 8 bits per component. But what about this? > > Doesn't 16-bits per component mean 4 hex digits per component? > > IOW, #RRRRGGGGBBBB (internally). IOW, even if my particular display only supports 2 hex digits per component, if Emacs supports 16 bits per component internally, doesn't that mean that it supports up to #RRRRGGGGBBBB? From drew.adams@oracle.com Tue Aug 4 19:25:42 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 5 Aug 2009 02:25:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL6,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n752PcmY015887 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 19:25:39 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n752PSS1008394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Aug 2009 02:25:29 GMT Received: from abhmt008.oracle.com (abhmt008.oracle.com [141.146.116.17]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n752PU6c005878; Wed, 5 Aug 2009 02:25:30 GMT Received: from dradamslap1 (/141.144.224.78) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Aug 2009 19:25:28 -0700 From: "Drew Adams" To: "'Juri Linkov'" Cc: <4033@debbugs.gnu.org> References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <87ws5j9rcv.fsf@mail.jurta.org> Subject: RE: bug#4033: 23.1; list-colors-display is misleading Date: Tue, 4 Aug 2009 19:25:26 -0700 Message-ID: <6875A66084B7406B8409F2C495A75D26@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoVTuZdnXz2o85zRHy9QT9NRbdW0AAJBkWw In-Reply-To: <87ws5j9rcv.fsf@mail.jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt008.oracle.com [141.146.116.17] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4A78ED99.002E:SCFSTAT5015188,ss=1,fgs=0 > > I have had at least one user state that he thought that, since the > > form shown is #RRGGBB, his colors had only that granularity. IOW, > > even if one's system allows colors of the form #RRRRGGGGBBBB (more > > colors), the color names are translated to hex strings of the form > > #RRGGBB (fewer colors). > > Could you show a formula that calculates the color granularity? > > We could use it to print colors in the short format #RRGGBB > for the smaller color space and #RRRRGGGGBBBB otherwise. What about something like this: (defun rgb-color-format-for-display () (let ((ncolors (display-color-cells (selected-frame))) (exp 0)) (while (> (lsh ncolors (- exp)) 1) (setq exp (1+ exp))) (setq exp (/ exp 12)) (format "#%%0%dx%%0%dx%%0%dx" exp exp exp))) For 16777216 colors, that gives #%02x%02x%02x, which seems right. In `list-colors-print', we would then do this: (insert (apply 'format (rgb-color-format-for-display) (mapcar (lambda (c) (lsh c -8)) (color-values (car color))))) IOW, replace the hard-coded "#%02x%02x%02x" with (rgb-color-format-for-display). But I guess Jason and Eli are saying that that wouldn't work or wouldn't be appropriate. It's still not clear to me. From drew.adams@oracle.com Tue Aug 4 19:36:23 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 5 Aug 2009 02:36:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.2 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n752aHq8016659 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 19:36:18 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n752aapb028901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Aug 2009 02:36:38 GMT Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n752aA1r021920; Wed, 5 Aug 2009 02:36:10 GMT Received: from dradamslap1 (/141.144.224.78) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Aug 2009 19:36:08 -0700 From: "Drew Adams" To: "'Juri Linkov'" Cc: <4033@debbugs.gnu.org> References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <87ws5j9rcv.fsf@mail.jurta.org> Subject: RE: bug#4033: 23.1; list-colors-display is misleading Date: Tue, 4 Aug 2009 19:36:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoVTuZdnXz2o85zRHy9QT9NRbdW0AAJBkWwAACCEsA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt006.oracle.com [141.146.116.15] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010205.4A78F018.00BF:SCFSTAT5015188,ss=1,fgs=0 > What about something like this: > > (defun rgb-color-format-for-display () > (let ((ncolors (display-color-cells (selected-frame))) > (exp 0)) > (while (> (lsh ncolors (- exp)) 1) (setq exp (1+ exp))) > (setq exp (/ exp 12)) > (format "#%%0%dx%%0%dx%%0%dx" exp exp exp))) > > For 16777216 colors, that gives #%02x%02x%02x, which seems right. > > In `list-colors-print', we would then do this: > > (insert (apply 'format (rgb-color-format-for-display) > (mapcar (lambda (c) (lsh c -8)) > (color-values (car color))))) > > IOW, replace the hard-coded "#%02x%02x%02x" with > (rgb-color-format-for-display). We would also want to first do that for one of the colors, to get the field width, then use that here: (indent-to (max (- (window-width) RGB-WIDTH) 44)) instead of hard-coding a width of 8, as now: (indent-to (max (- (window-width) 8) 44)) From drew.adams@oracle.com Tue Aug 4 19:58:26 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 5 Aug 2009 02:58:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_DRUGS_REL6,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n752wMLx018211 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 19:58:23 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n752wCif028781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Aug 2009 02:58:14 GMT Received: from abhmt005.oracle.com (abhmt005.oracle.com [141.146.116.14]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n752wbvq002483; Wed, 5 Aug 2009 02:58:37 GMT Received: from dradamslap1 (/141.144.224.78) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Aug 2009 19:58:12 -0700 From: "Drew Adams" To: <4033@debbugs.gnu.org>, "'Juri Linkov'" References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com><87ws5j9rcv.fsf@mail.jurta.org> <6875A66084B7406B8409F2C495A75D26@us.oracle.com> Subject: RE: bug#4033: 23.1; list-colors-display is misleading Date: Tue, 4 Aug 2009 19:58:10 -0700 Message-ID: <986CB10EE9314167B974BF1551275370@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoVTuZdnXz2o85zRHy9QT9NRbdW0AAJBkWwAAEnmMA= In-Reply-To: <6875A66084B7406B8409F2C495A75D26@us.oracle.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt005.oracle.com [141.146.116.14] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010204.4A78F545.008E:SCFSTAT5015188,ss=1,fgs=0 > > > I have had at least one user state that he thought that, since the > > > form shown is #RRGGBB, his colors had only that granularity. IOW, > > > even if one's system allows colors of the form #RRRRGGGGBBBB (more > > > colors), the color names are translated to hex strings of the form > > > #RRGGBB (fewer colors). > > > > Could you show a formula that calculates the color granularity? > > > > We could use it to print colors in the short format #RRGGBB > > for the smaller color space and #RRRRGGGGBBBB otherwise. This seems to DTRT, for printing with an RGB format that reflects the color support of the display: (defun list-colors-print (list) (let ((rgb-format (facemenu-rgb-format-for-display)) (col (car list)) rgb-width) (when (consp col) (setq col (car col))) (setq rgb-width (1+ (length (format rgb-format 1 1 1)))) (dolist (color list) (if (consp color) (when (cdr color) (setq color (sort color (lambda (a b) (string< (downcase a) (downcase b)))))) (setq color (list color))) (put-text-property (prog1 (point) (insert (car color)) (indent-to 22)) (point) 'face (list ':background (car color))) (put-text-property (prog1 (point) (insert " " (if (cdr color) (mapconcat 'identity (cdr color) ", ") (car color)))) (point) 'face (list ':foreground (car color))) (indent-to (max (- (window-width) rgb-width) 44)) (insert (apply 'format rgb-format (mapcar (lambda (c) (lsh c -8)) (color-values (car color))))) (insert "\n"))) (goto-char (point-min))) The question remains whether this is a useful/reasonable thing to do. From eliz@gnu.org Tue Aug 4 20:22:18 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 5 Aug 2009 03:22:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout1.012.net.il (mtaout1.012.net.il [84.95.2.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n753MEpb020911 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 20:22:15 -0700 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KNV00F00VVRSY00@i-mtaout1.012.net.il> for 4033@emacsbugs.donarmstrong.com; Wed, 05 Aug 2009 06:22:07 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.149.138]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KNV00D1WW0UBH10@i-mtaout1.012.net.il>; Wed, 05 Aug 2009 06:22:07 +0300 (IDT) Date: Wed, 05 Aug 2009 06:22:06 +0300 From: Eli Zaretskii Subject: Re: bug#4033: 23.1; list-colors-display is misleading In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Cc: jasonr@gnu.org, 4033@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: <83k51jndwh.fsf@gnu.org> References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> <4A78BD5A.8040901@gnu.org> <4A78C76C.7010001@gnu.org> > From: "Drew Adams" > Cc: <4033@emacsbugs.donarmstrong.com>, "'Eli Zaretskii'" > Date: Tue, 4 Aug 2009 16:55:44 -0700 > > Emacs supports 16 bits per component internally, doesn't that mean that it > supports up to #RRRRGGGGBBBB? It supports that, but it cannot actually display that if the display driver has only 8 bits per component. I.e., the extra bits get lost when the color is actually displayed. From drew.adams@oracle.com Tue Aug 4 22:34:20 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 5 Aug 2009 05:34:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n755YGP0032445 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 22:34:17 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n755Y69u032696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Aug 2009 05:34:08 GMT Received: from abhmt016.oracle.com (abhmt016.oracle.com [141.146.116.25]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n755YUZM006439; Wed, 5 Aug 2009 05:34:31 GMT Received: from dradamslap1 (/141.144.224.78) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Aug 2009 22:34:06 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" Cc: , <4033@debbugs.gnu.org> References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> <4A78BD5A.8040901@gnu.org> <4A78C76C.7010001@gnu.org> <83k51jndwh.fsf@gnu.org> Subject: RE: bug#4033: 23.1; list-colors-display is misleading Date: Tue, 4 Aug 2009 22:34:04 -0700 Message-ID: <33BD7D8E8A9A4543ABDC21D7A5042CEA@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoVe/ITqy8LetiZTBe0+3KEZrDD8gAD/JRQ In-Reply-To: <83k51jndwh.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt016.oracle.com [141.146.116.25] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010208.4A7919CF.00F0:SCFSTAT5015188,ss=1,fgs=0 > > IOW, even if my particular display only supports 2 hex digits > > per component, if Emacs supports 16 bits per component > > internally, doesn't that mean that it supports up to > > #RRRRGGGGBBBB? > > It supports that, but it cannot actually display that if the display > driver has only 8 bits per component. I.e., the extra bits get lost > when the color is actually displayed. I think that's what I just said, so it sounds like I'm on the same page: internally 16 bits, but a given display might be more limited. The idea then is to have Emacs use an RGB format that is appropriate for the user's display. If the display supports 8 bits per component, it would show #RRGGBB. If the display supports 16 bits per component, it would show #RRRRGGGGBBBB. If the display supports 12 bits per component, it would show #RRRGGGBBB. Whatever the display's support, the user would see the most appropriate RGB format. See the code I sent, which I think does that. From jasonrumney@gmail.com Tue Aug 4 23:57:59 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 5 Aug 2009 06:58:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n756vsel007192 for <4033@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 23:57:55 -0700 Received: by rv-out-0506.google.com with SMTP id f6so1399918rvb.1 for <4033@emacsbugs.donarmstrong.com>; Tue, 04 Aug 2009 23:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=r7RyJ9bACZcV0++im1utU4LEWG+ycI/0cpbZzDzjxAM=; b=fvClp7FOqmxE2pTbh1Tm6G2xIXFpOU7kyLzLfmRtUAi0hhh6gPYtD3uyt74iOd9ioo AWtFm7EIwWiBLlrNHaP81jWChNtV9p+h/N9aZiLSwI2fb3aaX5ib9aUi2gm/Rgtc9eIe zDONmhX3NBV0TnNGJVMEkHYHJjy2VbKADRigM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=v1Qd9yXVF0A6wpeZw/Z/sEKVVeBKsNcOchJ4D66tcu1xc7aodbVbLQKITY9V1BwAbt p8WGqgz9giNidVpoNMY9f+9yG0KNbhpunqtRhW45WpVeREZJGSOCzOnrEBk1HjFOY9It uVVCCSDwwKKsPdOz8oFXt9fUUNAMV32yF8wzg= Received: by 10.140.199.15 with SMTP id w15mr5964796rvf.99.1249455474096; Tue, 04 Aug 2009 23:57:54 -0700 (PDT) Received: from ?10.1.1.112? ([61.4.103.130]) by mx.google.com with ESMTPS id c20sm921663rvf.1.2009.08.04.23.57.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 23:57:53 -0700 (PDT) Sender: Jason Rumney Message-ID: <4A792D46.2080700@gnu.org> Date: Wed, 05 Aug 2009 14:57:10 +0800 From: Jason Rumney User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Drew Adams CC: "'Eli Zaretskii'" , 4033@debbugs.gnu.org Subject: Re: bug#4033: 23.1; list-colors-display is misleading References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> <4A78BD5A.8040901@gnu.org> <4A78C76C.7010001@gnu.org> <83k51jndwh.fsf@gnu.org> <33BD7D8E8A9A4543ABDC21D7A5042CEA@us.oracle.com> In-Reply-To: <33BD7D8E8A9A4543ABDC21D7A5042CEA@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Drew Adams wrote: > The idea then is to have Emacs use an RGB format that is appropriate for the > user's display. If the display supports 8 bits per component, it would show > #RRGGBB. If the display supports 16 bits per component, it would show > #RRRRGGGGBBBB. If the display supports 12 bits per component, it would show > #RRRGGGBBB. > The number of displays supporting more than 8 bits per component is so miniscule that I don't think it is really worth worrying about. I'm also not sure what display-color-cells reports on Windows 7 with 30, 36 or 48 bit color output enabled. If it reports anything > 2^24, then it does not reflect reality, which is that the standard Windows API's do not support more than 8 bits per component. From eliz@gnu.org Wed Aug 5 10:35:06 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 5 Aug 2009 17:35:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout3.012.net.il (mtaout3.012.net.il [84.95.2.7]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n75HZ1fp000361 for <4033@emacsbugs.donarmstrong.com>; Wed, 5 Aug 2009 10:35:02 -0700 Received: from conversion-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il (HyperSendmail v2004.12) id <0KNW00400ZAAFP00@i_mtaout3.012.net.il> for 4033@emacsbugs.donarmstrong.com; Wed, 05 Aug 2009 20:34:55 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.149.138]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KNW00EQMZI6JB62@i_mtaout3.012.net.il>; Wed, 05 Aug 2009 20:34:55 +0300 (IDT) Date: Wed, 05 Aug 2009 20:34:53 +0300 From: Eli Zaretskii Subject: Re: bug#4033: 23.1; list-colors-display is misleading In-reply-to: <4A792D46.2080700@gnu.org> X-012-Sender: halo1@inter.net.il To: Jason Rumney Cc: drew.adams@oracle.com, 4033@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: <83fxc6nozm.fsf@gnu.org> References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <83r5vro3po.fsf@gnu.org> <363A8C50DA1A48399649F2A7C5336AD3@us.oracle.com> <4A78BD5A.8040901@gnu.org> <4A78C76C.7010001@gnu.org> <83k51jndwh.fsf@gnu.org> <33BD7D8E8A9A4543ABDC21D7A5042CEA@us.oracle.com> <4A792D46.2080700@gnu.org> > Date: Wed, 05 Aug 2009 14:57:10 +0800 > From: Jason Rumney > CC: 'Eli Zaretskii' , 4033@emacsbugs.donarmstrong.com > > The number of displays supporting more than 8 bits per component is so > miniscule that I don't think it is really worth worrying about. Right. The file rgb.txt we distribute with Emacs uses only 8 bits per component, as do many (maybe most or even all) X distributions -- all those I could look up did. And that is another evidence to what Jason says above. From juri@jurta.org Wed Aug 5 14:36:36 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 5 Aug 2009 21:36:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out1.starman.ee [85.253.0.3]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n75LaZtw028371 for <4033@emacsbugs.donarmstrong.com>; Wed, 5 Aug 2009 14:36:36 -0700 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.69.104.cable.starman.ee [82.131.69.104]) by mx1.starman.ee (Postfix) with ESMTP id 668A43F41E6; Thu, 6 Aug 2009 00:36:29 +0300 (EEST) From: Juri Linkov To: "Drew Adams" Cc: 4033@debbugs.gnu.org Subject: Re: bug#4033: 23.1; list-colors-display is misleading Organization: JURTA References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com> <87ws5j9rcv.fsf@mail.jurta.org> <6875A66084B7406B8409F2C495A75D26@us.oracle.com> Date: Thu, 06 Aug 2009 00:35:43 +0300 In-Reply-To: <6875A66084B7406B8409F2C495A75D26@us.oracle.com> (Drew Adams's message of "Tue, 4 Aug 2009 19:25:26 -0700") Message-ID: <87ws5i9c5s.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > What about something like this: > > (defun rgb-color-format-for-display () > (let ((ncolors (display-color-cells (selected-frame))) > (exp 0)) > (while (> (lsh ncolors (- exp)) 1) (setq exp (1+ exp))) > (setq exp (/ exp 12)) > (format "#%%0%dx%%0%dx%%0%dx" exp exp exp))) > > For 16777216 colors, that gives #%02x%02x%02x, which seems right. > > In `list-colors-print', we would then do this: > > (insert (apply 'format (rgb-color-format-for-display) > (mapcar (lambda (c) (lsh c -8)) > (color-values (car color))))) > > IOW, replace the hard-coded "#%02x%02x%02x" with (rgb-color-format-for-display). > > But I guess Jason and Eli are saying that that wouldn't work or wouldn't be > appropriate. It's still not clear to me. I don't understand what is the reason to unnecessarily complicate this. In your original report you said that one user had some confusion with hex formats. Is this user using a system supporting more than 8 bits per component? -- Juri Linkov http://www.jurta.org/emacs/ From drew.adams@oracle.com Wed Aug 5 16:16:42 2009 Received: (at 4033) by emacsbugs.donarmstrong.com; 5 Aug 2009 23:16:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.2 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n75NGfe5005253 for <4033@emacsbugs.donarmstrong.com>; Wed, 5 Aug 2009 16:16:42 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n75NGX3A022081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Aug 2009 23:16:34 GMT Received: from abhmt020.oracle.com (abhmt020.oracle.com [141.146.116.29]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n75NGXnW009341; Wed, 5 Aug 2009 23:16:34 GMT Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 Aug 2009 16:16:31 -0700 From: "Drew Adams" To: "'Juri Linkov'" Cc: <4033@debbugs.gnu.org> References: <4B9B03BEE43E44B79206302B26E01B3A@us.oracle.com><87ws5j9rcv.fsf@mail.jurta.org><6875A66084B7406B8409F2C495A75D26@us.oracle.com> <87ws5i9c5s.fsf@mail.jurta.org> Subject: RE: bug#4033: 23.1; list-colors-display is misleading Date: Wed, 5 Aug 2009 16:16:33 -0700 Message-ID: <4AC1BBF95D2647949A2000504ECE564A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoWFNRG6YJlUVM8T0ON1CeanqZ+MwADTv5g In-Reply-To: <87ws5i9c5s.fsf@mail.jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt020.oracle.com [141.146.116.29] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010203.4A7A12D0.00F5:SCFSTAT5015188,ss=1,fgs=0 > I don't understand what is the reason to unnecessarily > complicate this. In your original report you said that one > user had some confusion with hex formats. Is this user using > a system supporting more than 8 bits per component? If no one sees the utility, then feel free to ignore and close the bug. To answer your question: Regardless of what that user's system supports, from Jason I've learned that only 8 bits can be effectively supported by Emacs (for nearly all systems) because of the system APIs that are available to Emacs. As to how Emacs should display the RGB that corresponds to a named color: I still think that TRT is to base that feedback on what `display-color-cells' tells about the user's display - its color support. If tomorrow the API limitations are alleviated, then that user feedback will automatically reflect Emacs's improved color support. It's easy enough to do that, as the code I sent shows. The difference is only a few lines of uncomplicated code. It's OK if you disagree about whether that should be done. From cyd@stupidchicken.com Sun Aug 9 19:37:38 2009 Received: (at control) by emacsbugs.donarmstrong.com; 10 Aug 2009 02:37:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.7 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7A2bb7f017562 for ; Sun, 9 Aug 2009 19:37:38 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 353B157E21E; Sun, 9 Aug 2009 22:38:30 -0400 (EDT) From: Chong Yidong To: control@debbugs.gnu.org Subject: close 4033 Date: Sun, 09 Aug 2009 22:38:30 -0400 Message-ID: <877hxcxujd.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii close 4033 thanks From unknown Wed Aug 20 01:18:23 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 07 Sep 2009 14:24:11 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator