From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#25890: `color-values` gives wrong value Date: Sat, 4 Mar 2017 12:40:12 -0800 (PST) Message-ID: <0fe39107-cf5e-4a55-b640-f14dcc1e122d@default> References: <<<<<<87zih7n2yt.fsf@pank.eu>>>>>> <<<<<<83r32jpr8b.fsf@gnu.org>>>>>> <<<<<<87bmtnryqr.fsf@drachen>>>>>> <<<<<<87d1e2tzt5.fsf@pank.eu>>>>>> <<<<<<8337eypb5l.fsf@gnu.org>>>>>> <<<<<<87vartx4qd.fsf@drachen>>>>>> <<<<<<56bad9de-8111-4962-a9e9-2dbf0084e004@default>>>>>> <<<<<<83wpc6la28.fsf@gnu.org>>>>>> <<<<<2cfd6280-34de-4751-b35f-ec7d47a16595@default>>>>> <<<<<83pohyky8i.fsf@gnu.org>>>>> <<<>>> <<<<83o9xikvop.fsf@gnu.org>>>> <<<1b96dc61-19bb-486b-a408-c3b3c15e113b@default>>> <<<83lgsll9ey.fsf@gnu.org>>> <<59441882-425e-4962-8760-70c505d991dd@default>> <<83lgslja4t.fsf@gnu.org>> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1488660071 21252 195.159.176.226 (4 Mar 2017 20:41:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Mar 2017 20:41:11 +0000 (UTC) Cc: michael_heerdegen@web.de, 25890@debbugs.gnu.org, rasmus@gmx.us To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 04 21:41:07 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckGUE-00050c-AI for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Mar 2017 21:41:06 +0100 Original-Received: from localhost ([::1]:36515 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ckGUK-0005He-8b for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Mar 2017 15:41:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ckGUE-0005HY-Po for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 15:41:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ckGUB-0000Gq-Ld for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 15:41:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42087) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ckGUB-0000GX-7K for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 15:41:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ckGUA-0006cg-IX for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 15:41:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Mar 2017 20:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25890 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25890-submit@debbugs.gnu.org id=B25890.148866003025410 (code B ref 25890); Sat, 04 Mar 2017 20:41:02 +0000 Original-Received: (at 25890) by debbugs.gnu.org; 4 Mar 2017 20:40:30 +0000 Original-Received: from localhost ([127.0.0.1]:40286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckGTd-0006bm-TP for submit@debbugs.gnu.org; Sat, 04 Mar 2017 15:40:30 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:40971) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckGTc-0006bW-5s for 25890@debbugs.gnu.org; Sat, 04 Mar 2017 15:40:28 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v24KeHme002701 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 4 Mar 2017 20:40:18 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v24KeHsQ012289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 4 Mar 2017 20:40:17 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v24KeDdM001633; Sat, 4 Mar 2017 20:40:15 GMT In-Reply-To: <<83lgslja4t.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:130198 Archived-At: > > > It should instead produce the most-significant digits. > > > > Why? >=20 > Because that's how colors are interpreted on X, I think you misunderstand `hexrgb-int-to-hex'. It does no color interpretation at all. It simply converts a decimal integer to a string of hex digits of a given length. If the prescribed length is too short for the number then the returned string clearly cannot represent the number accurately - as is documented. The fact that too few digits cannot represent the number is irrespective of whether those too few digits are MSB or LSB. It's up to code calling the function to DTRT wrt the number of digits it passes, just as it is up to the caller of `hexrgb-hex-to-int' to pass a hex string that does not represent an integer larger than what Emacs can handle. Here, for instance, is how `hexrgb-increment-hex' checks inputs to `hexrgb-int-to-hex' before it calls it: (<=3D (length (format (concat \"%X\") INT)) NB-DIGITS) The doc makes all of this pretty clear, I think. > which is where Emacs takes its ideas of how to > process these specs. Emacs interprets color specs. hexrgb does not. > See, for example, this man page: > https://linux.die.net/man/3/xparsecolor > (Emacs on X uses XParseColor internally in the > implementation of color-values.) I see nothing on that page that conflicts with the hexrgb code. In particular, this quote describes the hexrgb behavior too: "the string ''#3a7'' is the same as ''#3000a0007000'' Same color represented by both patterns. You use `hexrgb-int-to-hex' on each color component separately, and the maximum integer input is 65535 - as documented. (hexrgb-int-to-hex (hexrgb-hex-to-int "7000") 4 ) =3D=3D> "7000" (hexrgb-int-to-hex (hexrgb-hex-to-int "7") 1 ) =3D=3D> "7" It is Emacs, not hexrgb, that interprets such a hex value as a color component. And Emacs (correctly) interprets the component "7" in "#3a7" the same as it interprets the component "7000" in "#3000a0007000" - same color. > If you do it differently, sooner or later the results will > clash with what Emacs does, and yield subtly wrong values. hexrgb does not "do it" at all. hexrgb does not conflict with anything shown on the page you cited. > I will now bail out of this discussion. I have nothing more > to say about this issue. If you don't want to change > hexrgb.el, that's your prerogative. I've been clear that I would LOVE to fix a bug, if you can please point to one. Show some code that uses hexrgb and produces an incorrect result, for example.