GNU bug report logs - #41544
26.3; Possible incorrect results from color-distance

Previous Next

Package: emacs;

Reported by: Simon Pugnet <simon <at> polaris64.net>

Date: Tue, 26 May 2020 16:34:01 UTC

Severity: normal

Tags: patch

Found in version 26.3

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias EngdegÄrd <mattiase <at> acm.org>
Cc: tom <at> tromey.com, simon <at> polaris64.net, 41544 <at> debbugs.gnu.org
Subject: bug#41544: 26.3; Possible incorrect results from color-distance
Date: Mon, 01 Jun 2020 20:35:53 +0300
> From: Mattias EngdegÄrd <mattiase <at> acm.org>
> Date: Mon, 1 Jun 2020 19:24:45 +0200
> Cc: tom <at> tromey.com, simon <at> polaris64.net, 41544 <at> debbugs.gnu.org
> 
> > I'm worried because the way our automatic color mapping on
> > color-challenged TTYs works took some time to get right, and it worked
> > well for years.  If we want to risk rocking that particular boat som
> > profoundly, we had better had a very good reason, preferably several
> > good reasons.
> 
> Not quite sure what you are talking about here. You previously asked about the exact value of TTY_SAME_COLOR_THRESHOLD. Were you unsatisfied with my answer, and if so, in what respect?

I'm just looking at the changes.  I see a change in how colors are
converted to RGB triplets.  I see a change in what colors are
considered dark and light, with a new function which decides that that
is being used for frame background mode and in several lisp/term/
files, including 16-color terminals.  I'm asking why do we want to
make all those changes, which modify very basic aspects of our color
support on many terminals.




This bug report was last modified 4 years and 304 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.