RE: Eliminating a couple of independent face definitions

[Drew Adams]

> >> Having D copy from B is equivalent to having them both
> >> inherit from a new face A with B's previous definition.
> >
> > It is certainly not equivalent.
> > Just customize A to see the difference.
> 
> But A didn't exist before, so that's a new feature, not a 
> difference per se.  If we wanted, we could prevent the user
> from even knowing about A (have `customize-face' not support
> it), and they would be equivalent.

That comes back to my earlier suggestion of "inheriting" from constant
(uncustomizable) "faces".

> So surely this is better...?

I don't think so.  But it is a possibility.

I think it is better to make clear the difference: inheriting from a
customizable face and either "inheriting" from an uncustomizable "face" or
copying the default spec from an ordinary (customizable) face.

With `:copy-default' vs `:inherit' it is clear what is going on.  With just
`:inherit' it is less obvious what's happening.  I prefer my later suggestion to
my earlier one (which you are repeating).
> >> With the inheritance, the user does have the option
> >> to change both of them at once if desired.
> >
> > Precisely why they are not equivalent.  Read the thread, if 
> > you have not already, for why inheritance is not the be-all
> > and end-all.
> 
> If they don't want to customize A, they won't, and they'll
> then have exactly the same set of options that the copying
> idea would give them.

And if they do customize A then they end up with changes down the line to other
(inheriting) faces.  They cannot customize A without causing those side effects.

That's the point.  Users must take all of that into consideration when deciding
whether they want to customize A.  Which means that they also need to be aware
(become aware) of the inheritance relations - the fact that fiddling with A will
in fact affect faces B, D,...Z.

A user might well want to customize A, but without having repercussions
elsewhere.  S?he cannot do that, and that fact will affect whether s?he
ultimately "wants" to customize A.  After becoming fully aware of the
inheritance relations, that is. ;-)

Inheritance couples faces together.  That's both its strength and its weakness
(of course).  If a user can customize face A, then any face that inherits from
it (directly or indirectly) is affected.  It's as simple as that.

A pointer is not a copy.  Both pointers and copies are useful.  If the aim is to
get a full face definition without the trouble of coding it explicitly, then you
can either point to (inherit) an existing definition or copy one.

Note BTW (e.g. Tim) that inheritance does _not_ in fact point to an existing
face definition.  It points to a _current value_.  And just because face A might
have a nice, full default-attributes definition, covering light and dark
backgrounds, tty's, etc., that does not mean that the _current_ value of A is a
full definition.  Nothing prevents a user from customizing A to change it's
nice, full definition to simply a `Red' foreground in all cases.