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

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Fri, 5 Jun 2020 17:50:47 +0200
> Cc: tom@tromey.com, simon@polaris64.net, 41544@debbugs.gnu.org
> 
> > 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.

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.

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

On such terminals we will always have a problem, because "white" (and
"red" and "blue", and in fact any color specified by its name) is not
well-defined.  Their RGB values depend on external factors and
configurations that we cannot control, like X-level configuration of
the first 8 or 16 xterm colors.

IOW, this problem cannot be solved in principle, and we shouldn't even
try.  We currently have a solution that works "well enough" for those
cases, and I see no reason to make any significant changes in what we
arrived at after a long journey (which started during development of
Emacs 21).

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

This cannot be helped on a TTY.  Using #ffffffffffff is as good an
approximation as any other, and better than some which we tried in the
past.  I see no reason to make any changes due to this theoretical
issue.

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

This would make the result dependent on the frame, since the TTY type
can be different for different frames.  That would give rise to new
and exciting bugs, because these APIs currently don't accept a FRAME
argument (adding such an argument, while it can be made
backward-compatible, will take eons to propagate to Lisp code).

Again, I see no justification for such a change.  If we think these
minor deviations from theoretically perfect results may confuse
someone, we can document these pitfalls in any number of words we see
fit.