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

[Mattias Engdegård]

[I've left Tom and Simon out of the CC list to spare them the noise.]

6 juni 2020 kl. 09.29 skrev Eli Zaretskii <eliz@gnu.org>:

> 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.

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.

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.

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?