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 12:13:20 +0000
> Cc: rms@gnu.org, 36304@debbugs.gnu.org
> 
> On Sat, Jun 22, 2019 at 11:40 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > From: Pip Cet <pipcet@gmail.com>
> > > Date: Sat, 22 Jun 2019 11:23:35 +0000
> > > Cc: 36304@debbugs.gnu.org
> > >
> > > Here's a patch. I've read the documentation and it appears already to
> > > have been updated by someone so it no longer links to the X
> > > documentation.
> > >
> > > * src/xterm.c (x_parse_color): Translate #RGB notation to rgb:R/G/B
> > >   notation, which X handles slightly differently.
> >
> > Can this change be limited to xterm.c alone?
> 
> It'd leave us inconsistently still using the X standard in some
> places, but at first glance they appear to be documented to use the X
> standard, so maybe that's not wrong.

I'm not sure I understand what you mean by "the X standard".  Is that
the old or the new convention of how to interpret a given #RGB value?

> > I think we assume this color handling also in xfaces.c
> 
> Only via tty-color-standard-values, as far as I can see.
> 
> > and in lisp/term/tty-colors.el (and perhaps elsewhere, where TTY colors are used/defined).
> 
> tty-color-standard-values is documented to use the X convention, and
> it does. tty-color-desc is documented to return approximate results,
> and it does;

So we would need to change that as well, no?

> and it's only used for text terminals, right?

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.

> >  There's also lisp/color.el.
> 
> Anything in particular? As far as I can tell, the functions work
> properly using the new convention with this patch, although I am sure
> there are places that fail to deal with the 65280-as-maximum
> convention that nsfns.m uses.

If you convert a color to RGB and then back, is the result equal to
what you started with?  E.g., see

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29456#11

Or what about issues discussed in bug#25890 and bug#24273?

> > Am I missing something?
> 
> I don't think so, but I don't see anything, so far, that needs
> changing. I'm almost certain that some more places will need changing,
> but how do we find them?

By searching the code for "rgb" (case-insensitively)?  E.g., what does
parse_rgb_list return when the RGB value doesn't specify all the bits?
what about color_distance? etc.

My point is that the "old" interpretation of the #RGB values might
have seeped into more places than just that one xterm.c function, and
if we are going to change the interpretation, we should make sure we
do that consistently in all the affected places.