Question: How does color-lighten-name work?

Question: How does color-lighten-name work?

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

Hi folks,

I'm a bit puzzled with color-lighten-name...

This simple code:

(require 'color)
(let ((newbg "#102030"))
  (message "newbg: %s" newbg)
  (setq newbg (color-lighten-name newbg 10))
  (message "newbg: %s" newbg))

evaluated in the *scratch* buffer. will print the following:

newbg: #102030
newbg: #11ab23563501

Shouldn't the second colour spec have only 3 bytes?

Thanks for any enlightenment, because the docstrings are frugal
/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 1229 bytes --]

Re: Question: How does color-lighten-name work?

[Eli Zaretskii]

> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Date: Fri, 28 Oct 2022 08:23:16 +0200
> 
> (require 'color)
> (let ((newbg "#102030"))
>   (message "newbg: %s" newbg)
>   (setq newbg (color-lighten-name newbg 10))
>   (message "newbg: %s" newbg))
> 
> evaluated in the *scratch* buffer. will print the following:
> 
> newbg: #102030
> newbg: #11ab23563501
> 
> Shouldn't the second colour spec have only 3 bytes?

No, it uses the default format of 4 digits per component.

We could perhaps add an additional optional argument to specify how
many digits per component to produce.

Re: Question: How does color-lighten-name work?

[Robert Pluim]

>>>>> On Fri, 28 Oct 2022 10:09:34 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
    >> Date: Fri, 28 Oct 2022 08:23:16 +0200
    >> 
    >> (require 'color)
    >> (let ((newbg "#102030"))
    >> (message "newbg: %s" newbg)
    >> (setq newbg (color-lighten-name newbg 10))
    >> (message "newbg: %s" newbg))
    >> 
    >> evaluated in the *scratch* buffer. will print the following:
    >> 
    >> newbg: #102030
    >> newbg: #11ab23563501
    >> 
    >> Shouldn't the second colour spec have only 3 bytes?

    Eli> No, it uses the default format of 4 digits per component.

    Eli> We could perhaps add an additional optional argument to specify how
    Eli> many digits per component to produce.

By the principle of least surprise, perhaps default to the same number
of digits as the input?

Robert
-- 

Re: Question: How does color-lighten-name work?

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>,  emacs-devel@gnu.org
> Date: Fri, 28 Oct 2022 10:09:48 +0200
> 
> >>>>> On Fri, 28 Oct 2022 10:09:34 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
>     >> Date: Fri, 28 Oct 2022 08:23:16 +0200
>     >> 
>     >> (require 'color)
>     >> (let ((newbg "#102030"))
>     >> (message "newbg: %s" newbg)
>     >> (setq newbg (color-lighten-name newbg 10))
>     >> (message "newbg: %s" newbg))
>     >> 
>     >> evaluated in the *scratch* buffer. will print the following:
>     >> 
>     >> newbg: #102030
>     >> newbg: #11ab23563501
>     >> 
>     >> Shouldn't the second colour spec have only 3 bytes?
> 
>     Eli> No, it uses the default format of 4 digits per component.
> 
>     Eli> We could perhaps add an additional optional argument to specify how
>     Eli> many digits per component to produce.
> 
> By the principle of least surprise, perhaps default to the same number
> of digits as the input?

That'd be a backwards-incompatible change.  Too late for that, I
think.  So if we introduce that, it will have to be via the additional
argument.  (FWIW, I see no surprise in the current behavior; I was
actually surprised that it was surprising.  You do understand that the
#RGB notations are equivalent no matter how many bits per component we
show, yes?)

Re: Question: How does color-lighten-name work?

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]

Eli writes:
> You do understand that the #RGB notations are equivalent no matter how
many bits per component we show, yes?

When I'm under no stress, maybe... but not now definitely...

/PA

On Fri, 28 Oct 2022 at 13:26, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Robert Pluim <rpluim@gmail.com>
> > Cc: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>,
> emacs-devel@gnu.org
> > Date: Fri, 28 Oct 2022 10:09:48 +0200
> >
> > >>>>> On Fri, 28 Oct 2022 10:09:34 +0300, Eli Zaretskii <eliz@gnu.org>
> said:
> >
> >     >> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> >     >> Date: Fri, 28 Oct 2022 08:23:16 +0200
> >     >>
> >     >> (require 'color)
> >     >> (let ((newbg "#102030"))
> >     >> (message "newbg: %s" newbg)
> >     >> (setq newbg (color-lighten-name newbg 10))
> >     >> (message "newbg: %s" newbg))
> >     >>
> >     >> evaluated in the *scratch* buffer. will print the following:
> >     >>
> >     >> newbg: #102030
> >     >> newbg: #11ab23563501
> >     >>
> >     >> Shouldn't the second colour spec have only 3 bytes?
> >
> >     Eli> No, it uses the default format of 4 digits per component.
> >
> >     Eli> We could perhaps add an additional optional argument to specify
> how
> >     Eli> many digits per component to produce.
> >
> > By the principle of least surprise, perhaps default to the same number
> > of digits as the input?
>
> That'd be a backwards-incompatible change.  Too late for that, I
> think.  So if we introduce that, it will have to be via the additional
> argument.  (FWIW, I see no surprise in the current behavior; I was
> actually surprised that it was surprising.  You do understand that the
> #RGB notations are equivalent no matter how many bits per component we
> show, yes?)
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 3279 bytes --]