GNU bug report logs - #61188
30.0.50; color-lighten-name seems not to work

Previous Next

Package: emacs;

Reported by: "Mark Bestley" <gnu <at> bestley.co.uk>

Date: Mon, 30 Jan 2023 21:49:02 UTC

Severity: normal

Found in version 30.0.50

Full log


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

From: "Mark Bestley" <gnu <at> bestley.co.uk>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: stephen.berman <at> gmx.net, 61188 <at> debbugs.gnu.org
Subject: Re: bug#61188: 30.0.50; color-lighten-name seems not to work
Date: Thu, 02 Feb 2023 15:46:09 +0000
[Message part 1 (text/plain, inline)]
 * 

> On 1 Feb 2023, at 17:18, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> Date: Wed, 01 Feb 2023 14:11:13 +0000
>> From: "Mark Bestley" <gnu <at> bestley.co.uk>
>> Cc: 61188 <at> debbugs.gnu.org
>> 
>>> So I guess the current behavior is the intended one, and we should
>>> close this bug as wontfix?
>> 
>> No - I think the way 28.2 worked was correct. (for impact see highlight-indent.el which now does not work with a black background )
> 
> But by changing the tests to match what Emacs does now we explicitly
> said that we disagree, and that the current behavior is the correct
> one.
> 
>> What is the expected value of (color-lighten-name  "Black" 100) as I don't know where that test is. I would think the test is wrong. Did it run for 28.2?
> 
> The test is in test/lisp/color-tests.el.  The expected value is
> exactly what you said is wrong.
> 
>> Surely lightening Black fully should give white
> 
> How so?  The 100 is the percentage of the present luminance, and if
> that is zero, why do you expect it to become lighter?
> 
> See also the discussion in bug#54514, which was exactly about that.

I don't see a discussion there.
But I do understand and accept the rationale for changing * color-lighten-hsl*



> 
>> In 30 olor-lighten-name  "Black" of any positive value gives Black - surely this cannot be correct.
> 
> A zero multiplied by any percentage stays zero, no?  If you want a
> non-zero result, start with something close to black, but not actually
> black.
The issue is more with color-lighten-name and the use it has in highlight-indent.el
Here the background colour is increased or darkened so that a new background is  distinguishable from the original and it does that via varying the hue. In those terms increasing the hue from black to shades of grey and 100% takes you to white makes sense.

So just multiplying hue may not give the expected result here, The old reasoning for color-by-name might make some sense but I don't think we have the rationale why that was chosen.

So I understand why then change was made but I think that there will be broken code around which used color-lighten-name when emacs 29 is released.

Basically manipulation of coper values is more complex than at first thought.

I'll report this issue to highlight-indent.el and I think this bug can be closed,
[Message part 2 (text/html, inline)]

This bug report was last modified 2 years and 120 days ago.

Previous Next


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