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

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Wed, 3 Jun 2020 22:08:46 +0200
> Cc: Tom Tromey <tom@tromey.com>, Simon Pugnet <simon@polaris64.net>,
>         41544@debbugs.gnu.org
> 
> Now about the consolidation of the contrast colour predicate (color-dark-p): 
> as described previously in detail, the current code for doing so in various 
> places is unsatisfactory. For example, some of the methods employed classify 
> #00ff00 as a "dark" colour, leading to suboptimal results. (Try typing 
> #00ff00 in css-mode.)

Let's please discuss each problem in detail (I tried to understand
them from the log message you posted, but couldn't find rationale
there).

And in any case, I will prefer solutions that fix any problems
locally, not changes in low-level stuff used in many other places,
because the latter run the risk of introducing new bugs.  As the
problems are quite minor, AFAICT, solving them in unsafe ways is
something to be avoided.

> There are other bugs that are annoying in themselves, but need to be fixed in 
> order to make progress. Start Emacs in TTY mode with TERM=xterm-color and 
> evaluate (color-name-to-rgb "blue"). Notice how one of the components is 
> greater than 1 -- this is the unfortunate result of several bad decisions.

You mean, the component that is 1.0393?  What bad decisions caused
that, what problems does this small deviation causes in itself?  We
should weigh the gravity of the problems we try to solve here with the
potential of breaking working code elsewhere which relies on these
idiosyncrasies.

Thanks.