RE: Eliminating a couple of independent face definitions

[Drew Adams]

S> I'm not saying that *all* faces should be derived from some
S> base set, but Drew (and now you) seem to be saying that
S> derivation from a base set is useless.  The law of the
S> excluded middle does not apply to all vs. none, you know.
 
You are not saying *all*.  And I am not saying *none* (or all
vs none).  Please drop the bugaboo strawman, Stephen.  As a
matter of fact your argument repeats mine; it does not counter
it.

S> The basic problem is that faces are not colors.  Faces are
S> not fonts. (Where have I heard this before? ;-)  A face is
S> a semantic component, intended to express meaning.
S> Common meanings should have a common expression.

d> Inheritance should be based on similarity (preferably set
d> inclusion) of use (usage, use case, purpose), not just on
d> similarity of face attributes.

You used the word "semantic".  Good.  I might well have
included that word in the parens.  We both draw the same
distinction between a face as only a combination of appearance
attributes (no) and a face as having a purpose/meaning for
particular contexts (yes).

It is essentialy the same distinction that is made between
physical markup and logical markup - between `italic' and
`emphasis', for instance.

We have both said that inheritance should, in general, be used
for logical/usage/semantic entities, and *not* simply for
combinations of attributes (physical/appearance).  In my
words:

d> A new face should not inherit from face `region' just because
d> its default attributes are the same as the default attributes
d> of face `region', for example.

The idea that inheritance should be based on similarity of
usage/purpose/semantics rather than just similarity of value
(e.g. color, size) implies that it is a mistake to have faces
that are unrelated to font-locking be based on font-lock
faces.

A face whose purpose has something to do with comments could
be based on `font-lock-comment-face', but a face such as
`region' or `minibuffer-prompt' should probably not be based
on it - there is too little logical/semantical/usage
connection.

Why does this matter?  Coupling.  Unwanted side effects for a
descendent when you customize its ancestor.

d> IMO, it makes sense for a face B to inherit from another face
d> A _only_ when what is wanted is that customization of A
d> automatically is reflected in B.  When doing this, we should
d> _always_ expect and assume that A will be customized by users.
d> This is true no matter how "basic" A is.
d> 
d> This is why (IMO) it does _not_ make sense in general for
d> [all] faces to inherit from font-lock faces.


S> Thus, for text modes there should be an "emphasis" face, and
S> of course a "bogus whitespace" face for us pedants.  In
S> programming modes, "identifier" and "keyword" are common
S> semantics.  In compile modes, "info", "file", "position"
S> (usually line number), "function", "error", and "warning" are
S> common semantics.  In shell modes, several levels of "prompt".
S> Electric modes may want a "paren flash" face.  Search modes a
S> "hit" face and a "secondary hit" face.

Again you support what I said.  The important thing here is
that you have grouped faces into contexts, groups based on
usage/meaning.  (Whether or not those particular groups are
the best choices is beside the point.)

The point is that inheritance makes sense within such a group
(e.g., levels of prompt), and it makes a lot less sense (if
any) across unrelated groups (e.g. prompt, search hit, and
emphasis).

How did this discussion start?  Yidong seemed to be saying
(possible misinterpretation, admittedly) that it would be good
to get rid of duplicate face definitions, by which he
apparently meant faces that have different names but the same
attribute values.

That is the issue.  I argued that that would be misguided.
Such faces typically are *not* duplicates.  A face expresses
meaning (a usage and context); it is not identical to its
appearance.  You put it this way:

S> A face is a semantic component, intended to express meaning.
S> Common meanings should have a common expression.

I went a bit further and said that, in general, _only_ common
meanings or use patterns should have a common expression.

I have nothing against the examples of inheritance that you
argued for.  They are they same kinds of inheritance that I
argued for.  What I think is misguided is trying to boil
things down across meaning groups (usage contexts) based on
only equality of default attribute values.  That's the issue.

Looking for duplication of face definitions, and thus possible
candidates for inheritance (factoring), should not be based on
looking at their default attribute values.

It should be based on what the faces represent, what they do,
what they mean, how they are intended to be used.  When
duplicates of that kind are found, then yes, we can consider
factoring out the duplication by using inheritance.