GNU bug report logs -
#61188
30.0.50; color-lighten-name seems not to work
Previous Next
Full log
Message #26 received at 61188 <at> debbugs.gnu.org (full text, mbox):
[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.