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 wrote: > > From: Robert Pluim > > Cc: Pedro Andres Aranda Gutierrez , > emacs-devel@gnu.org > > Date: Fri, 28 Oct 2022 10:09:48 +0200 > > > > >>>>> On Fri, 28 Oct 2022 10:09:34 +0300, Eli Zaretskii > said: > > > > >> From: Pedro Andres Aranda Gutierrez > > >> 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