|
From: | Dmitry Gutov |
Subject: | 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 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
On 14.11.2019 16:41, Eli Zaretskii wrote:
Cc: 37774@debbugs.gnu.org From: Dmitry Gutov <dgutov@yandex.ru> Date: Thu, 14 Nov 2019 16:14:16 +0200How 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#131That 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.
[Prev in Thread] | Current Thread | [Next in Thread] |