bug#41544: 26.3; Possible incorrect results from color-distance

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> 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?