Re: master 64e25cd: More robust NS hex colour string parsing

[Mattias Engdegård]

13 juni 2020 kl. 17.58 skrev Eli Zaretskii <eliz@gnu.org>:

>> Try (color-values "#123"). The correct result is (#x1111 #x2222 #x3333).
> 
> Why is that the correct value?  I get (#x1010 #x2020 #x3030); why is
> that wrong?

It violates the HTML/CSS convention which was agreed upon in bug#36304 and 
followed by the other backends. Single-digit hex numbers are scaled by 
65535/15, two-digit numbers by 65535/255, and three-digit numbers by 65535/4095.

> Just follow the code, it should be very clear: those two branches
> always return a list of values.  No example should be needed.

An example could help resolve misunderstanding, and if we go back-and-forth on 
what you think is a simple matter it's a clear sign that one is definitely 
needed.

> No, that's not true, as should be obvious from examining the code.
> Previously, any "#..." string whose length was 4 or longer would
> return a list of values, even if it wasn't well-formed; now some of
> them will return nil.

(tty-color-values "#xyz") returned nil (and still does), contradicting your 
claim.

I meant that the manner of rejection remains unchanged, not the set of rejected 
arguments, which is a consequence of improved error-checking, very much by 
design.
Not only was it previously lacking, its coverage varied wildly between 
backends. That means that hardly any code could have abused the lax checking 
while still working on multiple platforms. Of course, the unpredictable 
behaviour on malformed input made this a very dubious endeavour in the first 
place.

> color-values-from-rgb-spec?

Thank you, but that would preclude addition of non-RGB formats in the future, 
such as HSV or XIE XYZ. Nothing in the interface forces the specification to be 
RGB. In fact, Xlib accepts several non-RGB formats.