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 14:59:53 +0300 Message-ID: <83r1us8kw6.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> 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="19435"; 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 14:01:11 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 1jhXVf-0004yV-2O for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jun 2020 14:01:11 +0200 Original-Received: from localhost ([::1]:36856 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhXVe-00007q-58 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jun 2020 08:01:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33426) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhXVW-00007O-GU for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 08:01:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39427) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jhXVW-00042x-7j for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 08:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jhXVW-0001ge-7B for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2020 08:01: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 12:01: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.15914448156396 (code B ref 41544); Sat, 06 Jun 2020 12:01:02 +0000 Original-Received: (at 41544) by debbugs.gnu.org; 6 Jun 2020 12:00:15 +0000 Original-Received: from localhost ([127.0.0.1]:50969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhXUk-0001f6-QQ for submit@debbugs.gnu.org; Sat, 06 Jun 2020 08:00:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48562) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhXUi-0001eM-GP for 41544@debbugs.gnu.org; Sat, 06 Jun 2020 08:00:13 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59478) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhXUd-0003iI-06; Sat, 06 Jun 2020 08:00:07 -0400 Original-Received: from [176.228.60.248] (port=4848 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jhXUX-0005Xp-L4; Sat, 06 Jun 2020 08:00:03 -0400 In-Reply-To: (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Sat, 6 Jun 2020 12:59:53 +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:181610 Archived-At: > From: Mattias Engdegård > Date: Sat, 6 Jun 2020 12:59:53 +0200 > Cc: 41544@debbugs.gnu.org > > Thank you all the same, but I'd like to fix this bug nevertheless. It is clearly a bug, and I'm one of those writing code calling color-values and thus being affected by it. Of course, if you can show some negative consequence of the suggested fix, then some alternative has to be considered. 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. That is, assuming we are still talking about the last patch you posted in this matter. > Instead of replying point-for-point, which can go on forever, let's try to break the stalemate; we are clearly talking past one another. I'm trying to understand your assumptions, and hope that you will do me the same courtesy. My assumption is that making changes for purely academic and/or aesthetic reasons is something that we should avoid. Time and again such changes just introduce bugs in other places, wasting our time and scarce resources, and leaving the overall quality of Emacs is none the better. I will therefore object to any low-level changes that don't fix clear-cut practical problems in some important functionality. > The values returned from color-values are scaled to a maximum of 65535 for all Emacs displays (except NS). Just because a TTY does not have a 'white' colour with RGB values (65535 65535 65535) does not mean that the scale is somehow different. > > In the case of TERM=xterm-color, the brightest colour (confusingly named "white") is (58853 58853 58853). This doesn't mean that 58853 is the maximum colour component value; it just means that the brightest colour is not pure white but something like a 90% grey, ie (0.9 0.9 0.9) in 1-normalised RGB notation. > > The method of using (color-values "#ffffffffffff") was a clever trick for obtaining the scale factor without having to know exactly what the maximum was for that frame, since parts of Emacs had different ideas of what range to actually use: it was common for some time to convert from 8 to 16 bit/channel by shifting 8 bits to the left. I've read through bug#25890 and bug#24273, as well as poured over the change history, and it seems very clear where this came from. > > However, the back-end code appears much more robust and regular now, and the code can be simplified, as well as avoiding the irregularities occurring with TTYs lacking a pure white colour. Surely there is no harm in that? Here you again lost me, sorry. You asked for understanding of your assumptions, but I cannot glean those assumptions from the text above. I don't even understand what each paragraph above tries to say, and/or with what argument of mine it attempts to argue. Specifically, what is there that is the current state of affairs, what is that _should_be_ the state of affairs in your opinion (a.k.a. "your assumptions", I presume), and why what we have now is in your opinion so bad that we must fix it?