[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: master 64e25cd: More robust NS hex colour string parsing
Date: Sat, 13 Jun 2020 14:59:56 +0300

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sat, 13 Jun 2020 12:17:09 +0200
> Cc: pipcet@gmail.com, emacs-devel@gnu.org
> 12 juni 2020 kl. 21.11 skrev Eli Zaretskii <eliz@gnu.org>:
> > The error checking aside, are
> > the return values of the original code the same as of the proposed
> > unified code?
> Returned values for well-formed input are identical

That's good to know, thanks.

> except the low bits in some cases on Windows (try "#123")

I don't think I understand what I should try; please elaborate.

> Malformed arguments are now consistently rejected.

How exactly are they rejected?  I see the return value of
parse_color_spec, but what happens in its callers, and what happens on
the Lisp levels when those callers are called?

> > At least tty-color-standard-values seems to never return nil for an
> > RGB spec, but now it will, right?  Can its callers cope with such a
> > return value?
> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]