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

[Mattias Engdegård]

5 juni 2020 kl. 14.27 skrev Eli Zaretskii <eliz@gnu.org>:

> There's some history to that: see bug#25890.

Thank you very much, that certainly gives some historical perspective!

> What bad results does this issue cause in practice?

The immediate bad result is that color-name-to-rgb returns a value that is (a) 
wrong and (b) outside the range of legal values for that function. Code calling 
it expect the value to be (a) correct and (b) within the range of legal values.

> (Btw, in a GUI session I see (0.0 0.0 1.0), so no problem there.)

Of course, but this was specifically in terminals where the colour closest to 
full white isn't.

>> The main problem is trusting "#ffffffffffff" to match a colour with the 
>> maximum range.
> 
> Why is that a problem, given the color representation we use in Emacs?

Because there is not always a matching (white) colour that has the maximum 
component value. The example I gave was for TERM=xterm-color, where the closest 
colour is (#xe5e5 #xe5e5 #xe5e5).

Note that this does not mean that the gamut for that terminal is somehow 
normalised with (0xe5e5 0xe5e5 0xe5e5) as perfect white; it is not. It is still 
the case that the maximum component value is either #xffff or #xff00; in this 
case #xffff.

Now, for non-TTY Emacs, we typically have an unlimited number of colours and 
(color-values "#ffffffffffff") returns the expected value. The same goes for a 
TTY where "white" is indeed white and not washed-out grey, such as TERM=linux.

> Sorry, you lost me here.  I don't understand what you are saying here
> and what does that have to do with the problem being discussed.

Let me try again:
(1) We know that the maximum colour component value is 65535 or 65280, 
depending on the platform (display system).
(2) color-name-to-rgb needs the maximum colour component value in order to 
normalise the result.
(3) color-name-to-rgb currently uses (color-values "#ffffffffffff") to obtain 
the maximum colour component value, but it is not always correct.
(4) Instead, we can just use 65535 or 65280 right away, which is fast and 
always correct.

The rest of my argument was merely discarding the possible alternative solution 
of redefining "white" as (255 255 255) for xterm-color.

> yields "(65535 65535 65535)", so I don't think I understand what
> problem you are concerned with here, and how can this cause a crash.

Sorry, I should have been more specific: this condition is present earlier, in 
frame-set-background-mode, before the --eval arguments are processed. This only 
pertains to the main part of the patch, which we have not yet discussed. I 
cannot fault you for being impatient!