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

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

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

> I have already pointed out the negative consequences: the fix you
> proposed changes the behavior and return values of a low-level API
> that is used in many places, both directly and indirectly. Thus, it
> runs a high risk of producing bugs and breaking code that works well
> enough now.

This is very speculative and hypothetical. Forgive me for being sceptical, but can you come up with a concrete and realistic example of what you think will break?

> That is, assuming we are still talking about the last patch you
> posted in this matter.

We were specifically talking about fixing the bug in color-name-to-rgb, I believe. It is subordinate to the main change, which we have not discussed at all. If you like, we could leave color-name-to-rgb alone, and we will see whether the change is needed when doing the actual work (color-dark-p).

> My assumption is that making changes for purely academic and/or
> aesthetic reasons is something that we should avoid.

That is a rather disparaging way of referring to fixes intended to make code working as advertised. 

> I don't even understand what each paragraph above tries to say, and/or
> with what argument of mine it attempts to argue.

You were saying that #ffffffffffff is as good an approximation as any other, and I was showing that it's not.

> Specifically, what is there that is the current state of affairs, what
> is that _should_be_ the state of affairs

The current state of affairs is that 'color-values' returns an incorrect value in certain cases. This can be fixed by making the code simpler and more robust.