bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: bug#36304: 27.0.50; request: switch to the superior HTML #RGB convention for colors
Date: Sat, 22 Jun 2019 18:05:36 +0300

> From: Pip Cet <pipcet@gmail.com>
> Date: Sat, 22 Jun 2019 14:41:30 +0000
> Cc: rms@gnu.org, 36304@debbugs.gnu.org
> 
> > > > 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?
> 
> We could. I don't have an opinion either way.
> 
> > > 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.
> 
> Okay, let's change it, then.

Thanks.

> > 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.
> 
> I don't think there's a way we can be absolutely certain to have fixed
> every potential problem, but we should try, yes.

Of course.  I only meant we should fix those we do find.  If the only
one is in tty-colors.el, then I guess that's it.  The rest will have
to be uncovered as people try using the new code.





reply via email to

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