RE: Eliminating a couple of independent face definitions

[Drew Adams]

T> Ignoring implementation issues, your suggestion appears to
T> meet the main objective i.e. making it easier for programmers
T> to do the right thing and have fully defined faces without
T> having to jump through all the hoops. I would agree that it is
T> a better solution than using inheritance with semantically
T> unrelated parents as it does appear to provide a solution that
T> does not compromise the strict form of preferred inheritance
T> and a way to improve the quality of default face values. 
T>
T> I would suggest that in addition to such enhancements to defface,
T> we need to provide guidelines in the manual on how to use
T> inheritance and copy and would go further and argue that for
T> semantically related faces, inheritance *should* be used to help
T> enhance consistency and allow users to customize a semantic
T> 'class' in one go.

Yes to guidelines in the manual and yes to encouraging inheritance among faces
with similar meaning/use.  As I said:

d> We would encourage programmers to use `:inherit' when the
d> new face (its use/meaning/purpose) is related to the
d> referenced face - that is, when they want a change in the
d> latter to be reflected in the former.

d> We would encourage them to use `:copy-default' when the
d> referenced face is unrelated and all they want to do is
d> reuse its default-attributes spec.

We would encourage them to use one or the other, to get full face definitions
able to handle different backgrounds etc.  And we would explain when it can be
good to use one vs the other.

We would also say why full definitions are important, and perhaps use an example
to point out characteristics of a full definition.