From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#41544: 26.3; Possible incorrect results from color-distance Date: Sat, 06 Jun 2020 10:29:04 +0300 Message-ID: <838sh0abzz.fsf@gnu.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> <3BBCFDD4-C14D-4628-91CB-2A0456A96FC7@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="103701"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tom@tromey.com, simon@polaris64.net, 41544@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 06 09:30:17 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 1jhTHV-000Qrd-Is for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jun 2020 09:30:17 +0200 Original-Received: from localhost ([::1]:39828 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhTHU-0005ns-8H for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jun 2020 03:30:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40774) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhTHH-0005nU-0A for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 03:30:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39038) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jhTHG-0001Hr-NQ for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 03:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jhTHG-0004yQ-Ie for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 03:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Jun 2020 07:30: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.159142857119057 (code B ref 41544); Sat, 06 Jun 2020 07:30:02 +0000 Original-Received: (at 41544) by debbugs.gnu.org; 6 Jun 2020 07:29:31 +0000 Original-Received: from localhost ([127.0.0.1]:50584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhTGc-0004x9-2L for submit@debbugs.gnu.org; Sat, 06 Jun 2020 03:29:31 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhTGa-0004wx-DD for 41544@debbugs.gnu.org; Sat, 06 Jun 2020 03:29:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57436) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhTGU-000176-Ai; Sat, 06 Jun 2020 03:29:14 -0400 Original-Received: from [176.228.60.248] (port=3805 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jhTGT-0006o1-DF; Sat, 06 Jun 2020 03:29:13 -0400 In-Reply-To: <3BBCFDD4-C14D-4628-91CB-2A0456A96FC7@acm.org> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Fri, 5 Jun 2020 17:50:47 +0200) 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:181591 Archived-At: > From: Mattias Engdegård > Date: Fri, 5 Jun 2020 17:50:47 +0200 > Cc: tom@tromey.com, simon@polaris64.net, 41544@debbugs.gnu.org > > > 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. That in itself is not bad, IMO. When I said "in practice", I meant practical problems this causes, and that inevitably involves some callers of that function (and the callers of those callers) that suffer problems which show on display or cause incorrect decisions to be made in specific Lisp applications. What you presented are theoretical difficulties that IMO don't yet justify any significant changes on this level, not by themselves. > > (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. On such terminals we will always have a problem, because "white" (and "red" and "blue", and in fact any color specified by its name) is not well-defined. Their RGB values depend on external factors and configurations that we cannot control, like X-level configuration of the first 8 or 16 xterm colors. IOW, this problem cannot be solved in principle, and we shouldn't even try. We currently have a solution that works "well enough" for those cases, and I see no reason to make any significant changes in what we arrived at after a long journey (which started during development of Emacs 21). > >> The main problem is trusting "#ffffffffffff" to match a colour with the maximum range. > > > > 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. This cannot be helped on a TTY. Using #ffffffffffff is as good an approximation as any other, and better than some which we tried in the past. I see no reason to make any changes due to this theoretical issue. > (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. This would make the result dependent on the frame, since the TTY type can be different for different frames. That would give rise to new and exciting bugs, because these APIs currently don't accept a FRAME argument (adding such an argument, while it can be made backward-compatible, will take eons to propagate to Lisp code). Again, I see no justification for such a change. If we think these minor deviations from theoretically perfect results may confuse someone, we can document these pitfalls in any number of words we see fit.