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 07:38:51 -0800 (PST) Message-ID: <59441882-425e-4962-8760-70c505d991dd@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>> 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 1488642035 32536 195.159.176.226 (4 Mar 2017 15:40:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Mar 2017 15:40:35 +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 16:40:31 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 1ckBnJ-0007ry-TV for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Mar 2017 16:40:30 +0100 Original-Received: from localhost ([::1]:35732 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ckBnQ-0006eK-5D for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Mar 2017 10:40:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ckBmv-0006NS-Vx for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 10:40:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ckBms-0002BG-NQ for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 10:40:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41964) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ckBms-0002B9-JP for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 10:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ckBms-0007jR-E5 for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 10:40:02 -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 15:40: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.148864194829638 (code B ref 25890); Sat, 04 Mar 2017 15:40:02 +0000 Original-Received: (at 25890) by debbugs.gnu.org; 4 Mar 2017 15:39:08 +0000 Original-Received: from localhost ([127.0.0.1]:40159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckBlz-0007hx-IM for submit@debbugs.gnu.org; Sat, 04 Mar 2017 10:39:07 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:32883) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckBlx-0007hH-Cc for 25890@debbugs.gnu.org; Sat, 04 Mar 2017 10:39:06 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v24FcuTo006651 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 4 Mar 2017 15:38:57 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v24Fct4a005843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 4 Mar 2017 15:38:56 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v24FcrWu019828; Sat, 4 Mar 2017 15:38:53 GMT In-Reply-To: <<83lgsll9ey.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: userv0021.oracle.com [156.151.31.71] 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:130186 Archived-At: > the problem is in hexrgb-int-to-hex. It does this: >=20 > (substring (format (concat "%0" (int-to-string nb-digits) "X") int) > (- nb-digits)) >=20 > which assumes that the digits to be produced, if n in the %0nX format > is too small and doesn't allow to produce all of them, are the > least-significant digits of the number. Correct. Which is just what its doc string says: If INT is too large to be represented with NB-DIGITS, then the result is truncated from the left. So, for example, INT=3D256 and NB-DIGITS=3D2 returns \"00\", since the hex equivalent of 256 decimal is 100, which is more than 2 digits. That doesn't claim that the result faithfully represents the decimal input value. It doesn't. But neither would truncating from the right represent it correctly. The doc string just describes the behavior, letting you know what the (inaccurate) return value is in such a case. Is there an advantage in truncating from the right? If so, what? Can you show how you would use such "corrected" behavior advantageously? To my mind, neither kind of truncation gives you anything useful, if what you need is to represent the same number faithfully. > It should instead produce the most-significant digits. Why? How would that be better? If the decimal number is too big for the allotted number of hex digits then it is just too big. > IOW, when #FFFFFF is converted to 16-bit per color component, it > should yield #FF00FF00FF00, not #FFFFFFFFFFFF. Where do you see `hexrgb-int-to-hex' being used as (I guess) you suppose? Where do you see #FFFFFF "converted" to #FFFFFFFFFFFF (let alone to #FF00FF00FF00). Sorry, but I just do not understand what you're trying to say. Are you perhaps thinking of using `hexrgb-int-to-hex' together with `hexrgb-hex-to-int', to "convert" from 6 hex digits to 12? In that case, the "conversion" would be from "FFFFFF" to "000000FFFFFF", which is correct, I think: (hexrgb-int-to-hex (hexrgb-hex-to-int "FFFFFF") 12) =3D> "000000FFFFFF" Or from 2 to 4 hex digits (since the function is used on each color component separately): (hexrgb-int-to-hex (hexrgb-hex-to-int "FF") 4) =3D> "00FF" Or for your "E0" example: (hexrgb-int-to-hex (hexrgb-hex-to-int "E0") 4) =3D> "00E0" I don't see any "conversion" from "E0" to "E0E0" (or to "E000", which is apparently what you suggest is called for). Can you please relate your message, whatever it might be, back to your initial statement that hexrgb 'produces "#FFFFFFFFE0E0" instead of "#FFFFFFFFE000" for the color mentioned by the OP'. AFAIK, the color mentioned by the OP was "light yellow". Do we agree so far? (I asked this once, but got no reply.) (And I asked what sexp using the hexrgb code you tried, but I got no answer there either.) I said that if you use (hexrgb-color-name-to-hex "light yellow") which is what I'd hope you would use, you do get "#FFFFFFFFE0E0". And I said that that is, AFAIK, correct, not incorrect. You say (I think) that the correct hex value for "light yellow" is, or should be, "#FFFFFFFFE000". But you haven't said why you think that. The color values for "light yellow" are: (65535 65535 57568). I asked if you thought those values are correct, but I got no reply. Let's assume they are correct (they are not from hexrgb code, anyway). If so, the question is how each of those color values should be represented using 4 hex digits. `hexrgb-int-to-hex' returns "FFFF" for each of the first two and "E0E0" for the third. I asked if you agreed that that is correct, and you said yes. To me, that means that it is correct for the 12-digit hex code for "light yellow" to be "#FFFFFFFFE0E0", which you apparently do not agree with. I get the impression that you are perhaps thinking that it is about "converting" FFFFE0 (not "light yellow") to FFFFFFFFE0E0 or to FFFFFFFFE000. If so, why do you think that, and where do you see the hexrgb code doing any such "conversion"? Sorry, but I just do not get your message. Could you perhaps show some code that points out the bug you think you have found? Could you show (with code) how using `hexrgb-int-to-hex' for "light yellow" or whatever gives the wrong hex representation? Saying that `hexrgb-int-to-hex' truncates from the left (i.e., drops the MSB) just repeats what its doc string says. It's not a bug but the declared behavior. If you see a _use_ of `hexrgb-int-to-hex' in hexrgb.el that leads to incorrect results because of that (intended) behavior, please point to it. I'd like to correct a bug in hexrgb, but so far I haven't been able to see what it is. You apparently think that `hexrgb-int-to-hex' should truncate from the right, i.e., drop the LSB, not the MSB, when the number is too large to be represented by the given number of hex digits. I don't see the advantage of that. If the number is too large then it is too large. For an integer value of 256 you would, I guess, prefer to see the hex representation "10" returned instead of "00". I don't see how that would help anything. I think the question is how code makes _use_ of `hexrgb-int-to-hex'. If the number to convert is too big for the number of hex digits allowed then there is no way to represent the decimal number with those few hex digits. I don't see an advantage to truncating from the right instead of the left. Can you give an actual example, where you would use a version of `hexrgb-int-to-hex' that is corrected according to you (presumably truncating at the right), where you can usefully make use of the return value? IOW, supposing a corrected `hexrgb-int-to-hex', how would you use it in a sexp to take advantage of the correction? AFAICS, if the decimal value cannot be represented with so few hex digits there is no sense in trying to use the result as if it represented the same number. But perhaps I'm missing something.