* 

> On 1 Feb 2023, at 17:18, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Date: Wed, 01 Feb 2023 14:11:13 +0000
>> From: "Mark Bestley" <gnu@bestley.co.uk>
>> Cc: 61188@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,