Defaulting faces to inherit deemed harmful [was: Stealing a default face from a non-ELPA package]

[Drew Adams]

> Personally, I wish more packages would define their
> faces in terms of inheritance from standard/built-in
> faces. This would mean a user could tweak the built-in
> faces to suit their preferences and the additional
> packages would inherit those tweaks without needing
> to be done individually.

Personally, I wish fewer packages, and default
Emacs itself, would define _fewer_ faces as
inheriting from other, standard/built-in faces -
in particular from font-lock faces.
___

tl;dr:
I expect that my opinion on this is a tiny minority
one.  I express it anyway, hoping it might open one
or two eyes or kindle a second thought here & there.
___

_Users_ can always do what you say: customize faces
to inherit from some face they want as parent.  And
they can do that at multiple levels: inheritance
hierarchy as deep or broad as you like - turtles
all the way...).
___

Font-lock faces, in particular, are defined to be
appropriate, by default, for particular _purposes_
(contexts) - e.g. comments.  Inheriting from them
willy nilly for faces that have nothing to do with
those purposes (e.g. non-code modes don't have
comments) creates unnecessary coupling.

The only face that has no specific purpose/context
is face `default'.  And that's as it should be.
In effect, all faces inherit from `default' (in
addition to having their own particularities).
___

Inheritance can be invisible at first sight, when
trying to figure out why a face looks as it does.

Inheriting by default is a bludgeon.  That blunt
club is often touted as the _reason_ for built-in
face inheritance by default:

> without needing to be done individually

A false problem, IMO.

1. Customizing a face _should_ in general be an
   individual choice, taking _context_/purpose
   into consideration.  (It's a similar decision
   to that of defining its default appearance.)

2. Nothing prevents customizing a face to inherit
   from another, including from standard/built-in
   faces.  It's _not at all difficult_ to do.
___

Inheriting by default has almost the same negative
effect as defining a face to have, by default, the
same appearance as face `default' (a practice that
`emacs -Q' used to embrace, and perhaps still does
here and there): You can't tell at a glance that
there's a separate/different face there.

Far better to use a different default appearance,
even if perhaps "ugly", so that users immediately
see that there's a separate face there that they
can customize to their liking.

The best way to introduce users to the fact that
they can easily customize faces is to let faces
stand out individually, by default.
___

I don't mean that each face needs a different
default definition.

I mean only that, other things being equal,
identical appearance works against recognizing
the presence of a different face.

What appearance to give a given face by default
is always a judgment call.  I mean only to add
this consideration to such a judgment, as one
more consideration, perhaps too often overlooked
in a zeal to concentrate face default appearance
with predefined inheritance.
___

One place _to_ perhaps use face inheritance by
default is in a theme.

And a library can similarly have some of its
faces inherit from some of _its_ other faces -
the `vc-*' faces inherit from `vc-state-base',
for example (with the tradeoff mentioned above:
lack of immediate recognition).  

A priori, most other uses of predefined
inheritance are  likely unwise/unhelpful, IMO.