GNU bug report logs - #37774
27.0.50; new :extend attribute broke visuals of all themes and other packages

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37774 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: Re: bug#37774: 27.0.50; new :extend attribute broke visuals of all
 themes and other packages
Date: Fri, 15 Nov 2019 00:42:40 +0200

On 14.11.2019 16:41, Eli Zaretskii wrote:
>> Cc: 37774 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Thu, 14 Nov 2019 16:14:16 +0200
>>
>>> How is :extend different from any other face attribute?
>>>
>>> The documentation of custom-theme-set-faces says that FACE should be a
>>> face spec, like in defface.  And the latter does override all the
>>> attributes, unless it uses :inherit.
>>>
>>> So I'm not unsure why you expected something else.
>>
>> *I* expected that going by your messages here and here:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37774#104
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37774#131
> 
> That was about custom-set-faces, not custom-theme-set-faces.  The
> former is a function we write into the user files, so it's hard to
> expect anyone to insert :extend there.

Okay, I didn't catch the distinction.

> custom-theme-set-faces is different: it's code written by theme
> authors, so we could expect them to cater to :extend.

Lots of themes out there, though. Lots of said authors. Who will have to 
do a version check and the splat-unquote thing, every one of them. I 
think that's pretty bad.

>> Then the backward compatibility problem is going to be bigger than I
>> thought. That's too bad. And my apologies to Jonas.
> 
> We are still discussing, so I see no need for apologies.
> 
> If the backward compatibility (or, rather, transparent DWIM-ish
> operation) is the overriding consideration, then you are actually
> saying that any face attribute we will introduce in the future will
> have to be treated the same?

I don't know what attributes we will introduce, and whether the default 
values will be a departure from the previous behavior like this one is.

But please note that having it a face attribute was your choice (or 
maybe Ergus's). I suggested using a symbol property instead. Though I 
was admittedly late to the party. Doing it in this way would side-step a 
number of questions like the ones you just asked.

> IOW, we will have to "inherit" it from
> the default face definition even if :inherit was not specified?  If
> so, how does a theme refuse to "inherit" in this way?

By setting it to an explicit nil value? Since the default is known, this 
should have the exact same effect.

BTW, does this scheme have a chance of working at all? IIUC, 
custom-theme-set-faces also handles faces which are not defined at all 
(yet), so inheriting an attribute from its default value might not be 
too easy.

Previous Next

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