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 16:57:38 +0300 Message-ID: <83img48ffx.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> <838sh0abzz.fsf@gnu.org> <83r1us8kw6.fsf@gnu.org> <020DE875-14A8-457A-9AE4-AA0925DB8997@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="103181"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 15:58:13 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 1jhZKv-000Qk9-0t for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jun 2020 15:58:13 +0200 Original-Received: from localhost ([::1]:42270 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhZKu-0004hj-3r for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jun 2020 09:58:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42294) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhZKk-0004hN-9O for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 09:58:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40705) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jhZKk-0005oD-06 for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 09:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jhZKj-000741-V1 for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 09:58:01 -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 13:58:01 +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.159145187527142 (code B ref 41544); Sat, 06 Jun 2020 13:58:01 +0000 Original-Received: (at 41544) by debbugs.gnu.org; 6 Jun 2020 13:57:55 +0000 Original-Received: from localhost ([127.0.0.1]:52251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhZKd-00073h-Ep for submit@debbugs.gnu.org; Sat, 06 Jun 2020 09:57:55 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhZKb-00073T-NT for 41544@debbugs.gnu.org; Sat, 06 Jun 2020 09:57:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60550) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhZKW-0005o0-4R; Sat, 06 Jun 2020 09:57:48 -0400 Original-Received: from [176.228.60.248] (port=4660 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jhZKU-0004n0-GX; Sat, 06 Jun 2020 09:57:47 -0400 In-Reply-To: <020DE875-14A8-457A-9AE4-AA0925DB8997@acm.org> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Sat, 6 Jun 2020 15:29:31 +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:181618 Archived-At: > From: Mattias Engdegård > Date: Sat, 6 Jun 2020 15:29:31 +0200 > Cc: 41544@debbugs.gnu.org > > 6 juni 2020 kl. 13.59 skrev Eli Zaretskii : > > > I have already pointed out the negative consequences: the fix you > > proposed changes the behavior and return values of a low-level API > > that is used in many places, both directly and indirectly. Thus, it > > runs a high risk of producing bugs and breaking code that works well > > enough now. > > This is very speculative and hypothetical. Forgive me for being sceptical, but can you come up with a concrete and realistic example of what you think will break? None at this time. But bitter experience has taught me that they will almost certainly come. They always do. > > My assumption is that making changes for purely academic and/or > > aesthetic reasons is something that we should avoid. > > That is a rather disparaging way of referring to fixes intended to make code working as advertised. If the problem is that the documentation doesn't match the behavior, it is much easier for me to agree to amend the documentation. In this case, I think a Lisp program that interprets the documentation too literally is making a mistake, but I'm not opposed to make that clearer in the docs. > > I don't even understand what each paragraph above tries to say, and/or > > with what argument of mine it attempts to argue. > > You were saying that #ffffffffffff is as good an approximation as any other, and I was showing that it's not. Then I'm not convinced, sorry. > > Specifically, what is there that is the current state of affairs, what > > is that _should_be_ the state of affairs > > The current state of affairs is that 'color-values' returns an incorrect value in certain cases. This can be fixed by making the code simpler and more robust. We've made a full circle: I was talking about the effects on the callers of color-values and color-name-to-rgb, and explicitly asked that we don't limit ourselves to these functions alone. If there are no problems caused to the callers of these functions, then I think we should leave the code alone.