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

Message #199 received at 41544 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41544 <at> debbugs.gnu.org
Subject: Re: bug#41544: 26.3; Possible incorrect results from color-distance
Date: Wed, 19 Aug 2020 13:28:52 +0200

[CC list trimmed]

19 aug. 2020 kl. 12.11 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:

> I'm not quite sure I follow you here, but could these other computations
> also be fixed, with a defcustom to switched between the two computation
> methods?

Technically yes, but is there is a reason for users to adjust this particular behaviour? Users dissatisfied with the outcome of the existing algorithms typically curse and set colours explicitly (or suffer in silence); they are unlikely to set a 'use different algorithm' variable.

To be precise, the computations I suppose we are talking about are located in:

 frame-set-background-mode (frame.el:1184)
 xterm-maybe-set-dark-background-mode (xterm.el:1122)
 rxvt-set-background-mode (rxvt.el:198)
 terminal-init-w32console (w32console.el:89)

which all use the predicate (r+g+b)/3 < 0.6 to determine if a colour is dark.
It is also mentioned in a comment in pc-win.el:57.

I believe it to be suboptimal but have no plans to do anything about it.
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.