bug#36304: 27.0.50; request: switch to the superior HTML #RGB convention for colors

[Eli Zaretskii <eliz@gnu.org>]

> From: Pip Cet <pipcet@gmail.com>
> Date: Sat, 22 Jun 2019 15:33:14 +0000
> Cc: rms@gnu.org, 36304@debbugs.gnu.org
> 
> > > > Yes, but we nowadays support text terminals that can display 24-bit
> > > > colors, and having their colors display differently from the same
> > > > color on X is just asking for bug reports.
> > > Okay, let's change it, then.
> > Thanks.
> 
> While I was there, I've also made it accept upper-case hex digits
> (previously, #0F0 was accepted but #F00 wasn't), and fixed the ranges
> so rgb:f/f/f translates to (65535 65535 65535) rather than (255 255
> 255).

Thanks.

A few comments:

> * lisp/term/tty-colors.el (tty-color-standard-values): Change
>   interpretation of #RGB strings to match CSS rather than X
>   conventions. Allow upper-case digits. Fix rgb:R/G/B interpretation.

Our convention is to use two spaces between sentences in documentation
and comments.  That includes log entries.

> -The returned value reflects the standard X definition of COLOR,
> +The returned value reflects the standard Emacs definition of COLOR,

This should include some reference to where "standard Emacs
definition" of colors can be found.  For X, we didn't need that,
because X docs is not our responsibility, and there's a plenty out
there.

> -    (cond ((and (>= len 4) ;; X-style "#XXYYZZ" color spec
> +    (cond ((and (>= len 4) ;; "#XXYYZZ" color spec

Is #XXYYZZ no longer considered "X-style"?

>  	   ;; Translate the string "#XXYYZZ" into a list
> -	   ;; of numbers (XX YY ZZ).  If the primary colors
> -	   ;; are specified with less than 4 hex digits,
> -	   ;; the used digits represent the most significant
> -	   ;; bits of the value (e.g. #XYZ = #X000Y000Z000).
> +	   ;; of numbers (XX YY ZZ).  If fewer than 4 hex
> +	   ;; digits are used, they represent the fraction
> +	   ;; of the maximum value (#XYZ = #XXXXYYYYZZZZ).

IMO, this part makes the text confusing: "4 hex digits" can be
interpreted as referring to the entire XXYYZZ thing, whereas you
really mean the number of digits for each primary color R, G, and B.
Also, I envision people who will struggle with the exact meaning of
"the fraction of the maximum value".  Where the previous text and the
example could be easily generalized to understand how we interpret
#ABCDEF, the proposed text, by giving an example only for a single hex
digit per primary color, does not lend itself to such an easy
generalization.

Finally, this is just part of the patch, isn't it?  The xterm.c part
is not here, and neither are the documentation parts.  Did I miss
something?