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

[Eli Zaretskii]

> Cc: 37774@debbugs.gnu.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 8 Dec 2019 02:42:42 +0200
> 
> On 07.12.2019 21:14, Eli Zaretskii wrote:
> 
> > Our goal is to allow themes "inherit" the :extend attribute without
> > having to specify it in their face specs, unlike with other
> > attributes.  That's the only goal;
> 
> But that's exactly what it does.

It does, but the implementation is too general, and might affect other
use cases.

> > we don't want :extend to behave
> > differently from other face attributes in any other context.
> 
> What other contexts do you have in mind?

Any context other than a theme defining a face.

> What *shouldn't* it do?

What we do with any other face attribute.

> > If you are saying that we cannot make this change apply only to face
> > definitions by themes,
> 
> What other face definitions are there? There's defface, of course, which 
> we treat differently. And there are theme definitions (both third-party 
> and "user theme").

All the other situations where face-spec-recalc is called.  You listed
at least some of them up-thread.

> > then it means we don't really understand what
> > we could break here, and then I don't think I want this change in
> > Emacs 27.  Sorry, it's too risky.
> 
> What about the existing risk of breaking every theme out there by doing 
> nothing?

If we don't have a safe solution, we will have to live with that risk,
unfortunately.

> > But I don't
> > consider myself an expert on these matters, so if you say we cannot
> > differentiate between general face definition and what themes do, so
> > be it.)
> 
> What's a "general face definition"?

Everything except theme definition of faces.