RE: Eliminating a couple of independent face definitions

[Stephen J. Turnbull]

Drew Adams writes:
 > Example: command `doremi-all-faces-fg+' lets you incrementally
 > modify all face foregrounds at once (hue, saturation, brightness,
 > red, green, and/or blue).  Obviously such a command is limited, but
 > in combination with others it can be a real help for customizing -

Sure, it's a help with customization, but it does not address the
basic problem.

 > I'd be interested in hearing more arguments in favor of faces inheriting from
 > faces (e.g. "basic" faces).

The basic problem is that faces are not colors.  Faces are not fonts.
(Where have I heard this before? ;-)  A face is a semantic component,
intended to express meaning.  Common meanings should have a common
expression.  Thus, for text modes there should be an "emphasis" face,
and of course a "bogus whitespace" face for us pedants.  In
programming modes, "identifier" and "keyword" are common semantics.
In compile modes, "info", "file", "position" (usually line number),
"function", "error", and "warning" are common semantics.  In shell
modes, several levels of "prompt".  Electric modes may want a "paren
flash" face.  Search modes a "hit" face and a "secondary hit" face.

For many simple modes, such basic faces will be enough, and used as
is.  However, modes of medium complexity may want to inherit in order
to allow customization of that mode without affecting others,
especially modes with lots of faces where customization of one face
may collide with the basic definition of another, and the user prefers
to change the second face in the mode where it collides but not
elsewhere.  This has happened to me occasionally, though by now most
of my customizations are inches thick in moss.

It might also be useful to have semantically derived faces, so that
"strong emphasis" (introduced to support markup modes like HTML) would
derive from "emphasis" (but this is speculative).  On the same theme,
"keyword" might derive from "identifier".