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

["Mattias Engdegård" <mattiase@acm.org>]

[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?