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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: jonas@bernoul.li, 37774@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 15 Nov 2019 00:42:40 +0200
> 
> > 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.

It's not bad, because IMO most faces don't need to be changed at all.
That Jonas and others went ahead and decided to change almost all of
them is IMO a mistake.

> > 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.

It doesn't matter if the default face definition uses that attribute,
does it?

> 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.

Using a symbol property is extremely unclean, IMO, and would
unnecessarily complicate the face-merging code.

> > 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?

That does nothing if the :inherit is not explicit.  Unless, again, we
complicate the heck out of the face-merging code.

> 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.

Probably not, and I said up front I didn't see how doing this will
fly.

I guess the best solution at this point is to require all themes to
make the appropriate changes.