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

[Dmitry Gutov]

On 23.10.2019 21:04, Eli Zaretskii wrote:

> > > AFAIU, that's a list of faces one particular user decided to customize
> > > to have them extended.  It's a far cry from the list of faces that
> > > actually need to be extended, lest some important functionality will
> > > suffer.  IOW, we need some rationale for each face, so that we could
> > > consider that and decide whether or not to extend each one by default.
> >
> > Magit's maintainer will decide for each face, sure.
>
> I don't mind if package maintainers want to make that decision by
> themselves, but if that is the case, I don't think there's anything
> left to do for this bug report?  I though some action will be required
> from us, that's why I asked all those questions.

We should define and document a "migration path", e.g. say what a 
package author should do if they have a face which needs to be extended, 
preferably without breaking compatibility with Emacs 26.

> > But I don't really see much a difference between having 2 and 20 faces
> > that will need to be updated, if it's within one package.
>
> It's a difference between a small number and a very large number.
> Theoretically, someone could argue that a change that requires to
> modify lots of faces shouldn't be so unconditional, or shouldn't be
> the default, or should have a "fire escape", or something to that
> effect.  But if people don't mind changing their faces, then such
> fears have no basis, and we are good with what we have.

A "fire escape" would depend on a user's config, right? I don't like the 
sound of that approach, personally.

> > Even if it's just 2, do we have a recommended way to write their
> > definitions in third-party packages in a way that's compatible with
> > Emacs 26?
>
> The best way is to inherit from some suitable parent face, I think.

A lot of face don't inherit from anything on purpose. Anyway, I've 
pinged Magit's maintainer, let's see what he says.

> > > If too many faces in unbundled packages indeed need to change in that
> > > way, we should consider additional measures.  That's why we need good
> > > reasons for extending each face, not just "because they were before"
> > > or because people were used to see them extended.
> >
> > Those are not the worst reasons, though.
>
> Not sure I understand in what sens did you use "the worst" here.

"People were used to ..." is basically 99% of the arguments that were 
given in all past discussions for not changing defaults to be more 
"modern" or whatever. And there's some merit to that.