From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#41544: 26.3; Possible incorrect results from color-distance Date: Fri, 5 Jun 2020 17:50:47 +0200 Message-ID: <3BBCFDD4-C14D-4628-91CB-2A0456A96FC7@acm.org> References: <5C4A633D-8222-4439-BE37-9B8674F1DA6D@acm.org> <87r1v2aat3.fsf@tromey.com> <9902865C-01B4-4E50-A433-DBC8B8311234@acm.org> <83tuzueogo.fsf@gnu.org> <6272275C-560C-4437-90F1-2A8294D27019@acm.org> <83o8q2elja.fsf@gnu.org> <83mu5mel4o.fsf@gnu.org> <77F1DDD3-A69F-40ED-902D-74986D5E6596@acm.org> <83y2p5cumz.fsf@gnu.org> <83blm0cjlz.fsf@gnu.org> <83367ccf8w.fsf@gnu.org> <624D7FB8-A836-4A7E-8895-47E867214504@acm.org> <83o8pyc4bq.fsf@gnu.org> <55D73CA5-1EFB-4B0A-8F8B-FDA1D39F51BF@acm.org> <835zc5bsut.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="81112"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tom@tromey.com, simon@polaris64.net, 41544@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 05 18:01:33 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jhEmj-000L1p-JE for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Jun 2020 18:01:33 +0200 Original-Received: from localhost ([::1]:60534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhEmi-0006QY-IB for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Jun 2020 12:01:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58542) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhEcY-000696-RT for bug-gnu-emacs@gnu.org; Fri, 05 Jun 2020 11:51:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38089) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jhEcY-0004cu-GK for bug-gnu-emacs@gnu.org; Fri, 05 Jun 2020 11:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jhEcY-0000vH-Dv for bug-gnu-emacs@gnu.org; Fri, 05 Jun 2020 11:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Jun 2020 15:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41544 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 41544-submit@debbugs.gnu.org id=B41544.15913722613538 (code B ref 41544); Fri, 05 Jun 2020 15:51:02 +0000 Original-Received: (at 41544) by debbugs.gnu.org; 5 Jun 2020 15:51:01 +0000 Original-Received: from localhost ([127.0.0.1]:49635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhEcW-0000uy-NE for submit@debbugs.gnu.org; Fri, 05 Jun 2020 11:51:01 -0400 Original-Received: from mail213c50.megamailservers.eu ([91.136.10.223]:32280 helo=mail194c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhEcT-0000uk-G5 for 41544@debbugs.gnu.org; Fri, 05 Jun 2020 11:50:59 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1591372250; bh=6SrGCdAfxtbqzwTu91mjae0VBmB3/8RJwF/b6pOPHtI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=FAbvCmx1vukJHA1f0MmvPdo0cY9Y+MLWB6O3xOJVdqtQFfA1EH8Rxk3Xd6LeHI3Zi LgwUZVmzTN1UGkZIsYNvPQ3WtJYFDVhQNYpyvKkPifJA7xnLURuz/tH/gcsdXb1OJF Kot2QJtHCUQU/Mmb5pLR6t/24FCRADIz+xbxKzOQ= Feedback-ID: mattiase@acm.or Original-Received: from stanniol.lan (c-4e4ae655.032-75-73746f71.bbcust.telenor.se [85.230.74.78]) (authenticated bits=0) by mail194c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 055FolQo028398; Fri, 5 Jun 2020 15:50:49 +0000 In-Reply-To: <835zc5bsut.fsf@gnu.org> X-Mailer: Apple Mail (2.3445.104.14) X-CTCH-RefID: str=0001.0A782F21.5EDA6969.0073:SCFSTAT68638221, ss=1, re=-4.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: -4.000 X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=KsozJleN c=1 sm=1 tr=0 a=klNLuyVZdLUgl+K5Uafb2A==:117 a=klNLuyVZdLUgl+K5Uafb2A==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=mDV3o1hIAAAA:8 a=-VOMddSL8ucwYjIa_j4A:9 a=CjuIK1q_8ugA:10 a=_FVE-zBwftR9WsbkzFJk:22 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:181571 Archived-At: 5 juni 2020 kl. 14.27 skrev Eli Zaretskii : > There's some history to that: see bug#25890. Thank you very much, that certainly gives some historical perspective! > What bad results does this issue cause in practice? The immediate bad result is that color-name-to-rgb returns a value that = is (a) wrong and (b) outside the range of legal values for that = function. Code calling it expect the value to be (a) correct and (b) = within the range of legal values. > (Btw, in a GUI session I see (0.0 0.0 1.0), so no problem there.) Of course, but this was specifically in terminals where the colour = closest to full white isn't. >> The main problem is trusting "#ffffffffffff" to match a colour with = the maximum range. >=20 > Why is that a problem, given the color representation we use in Emacs? Because there is not always a matching (white) colour that has the = maximum component value. The example I gave was for TERM=3Dxterm-color, = where the closest colour is (#xe5e5 #xe5e5 #xe5e5). Note that this does not mean that the gamut for that terminal is somehow = normalised with (0xe5e5 0xe5e5 0xe5e5) as perfect white; it is not. It = is still the case that the maximum component value is either #xffff or = #xff00; in this case #xffff. Now, for non-TTY Emacs, we typically have an unlimited number of colours = and (color-values "#ffffffffffff") returns the expected value. The same = goes for a TTY where "white" is indeed white and not washed-out grey, = such as TERM=3Dlinux. > Sorry, you lost me here. I don't understand what you are saying here > and what does that have to do with the problem being discussed. Let me try again: (1) We know that the maximum colour component value is 65535 or 65280, = depending on the platform (display system). (2) color-name-to-rgb needs the maximum colour component value in order = to normalise the result. (3) color-name-to-rgb currently uses (color-values "#ffffffffffff") to = obtain the maximum colour component value, but it is not always correct. (4) Instead, we can just use 65535 or 65280 right away, which is fast = and always correct. The rest of my argument was merely discarding the possible alternative = solution of redefining "white" as (255 255 255) for xterm-color. > yields "(65535 65535 65535)", so I don't think I understand what > problem you are concerned with here, and how can this cause a crash. Sorry, I should have been more specific: this condition is present = earlier, in frame-set-background-mode, before the --eval arguments are = processed. This only pertains to the main part of the patch, which we = have not yet discussed. I cannot fault you for being impatient!