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

[Eli Zaretskii <eliz@gnu.org>]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sat, 13 Jun 2020 17:39:29 +0200
> Cc: pipcet@gmail.com, emacs-devel@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?

> >> Not sure what you mean here. Mind giving a concrete example?
> > 
> > The first two branches of the 'cond' would always return a list before
> > your changes, but after your changes they could return nil if
> > color-values-from-numeric-string (not the best name, btw) returns nil
> > and the input is of one of the two forms parsed by those two branches.
> 
> This is still a tad vague and speculative.

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

> As far as I can tell, well-formed arguments yield correct values and
> others are rejected in the same way as before

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.

> I don't particularly like that function name either. What about one of these:
> 
>  parse-color
>  parse-color-spec
>  parse-color-string
>  color-values-from-spec
>  color-from-string-spec
>  color-spec-to-values

color-values-from-rgb-spec?