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

[Eli Zaretskii]

> Cc: 37774@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 23 Oct 2019 23:28:50 +0300
> 
> > 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.

We can do that in NEWS, if what's already there is not clear enough.

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

"Fire escape" in this context means a way to get the old behavior
without inordinately too much work on the part of the user.

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

Thanks.

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

No, in past discussions people usually also brought up
functionality-related arguments, not just that they are used to the
old behavior.