RE: Eliminating a couple of independent face definitions

[Drew Adams]

> As Drew said, faces need to make sense in their context.
>
> I just spent some time picking sensible faces from the font-lock-*
> palette for dired+, which by default defines its own static faces.

That's my fault.  I defined the default Dired+ face colors only for light
backgrounds.  I DTRT for Icicles long ago, but I never got around to doing the
same for Dired+.

I've done that now, thanks to your reminder.  (However, I intentionally do not
use face inheritance - see below.)

FWIW, for this I simply use the complements of the light-background default
colors as the dark-background colors.  That is not necessarily ideal, but it at
least is reasonable and consistent.  It is also very quick to do, given some
code (e.g. hexrgb.el or palette.el) that quickly gives you color complements.

Such defaulting could presumably even be built-in (optionally).  For example, we
could allow a dark-background setting to be just a symbol `complement' or
`:complement', which would mean to pick up the `t' setting or the
light-background setting (if present) and use its complement.  Likewise for
light-background setting - whatever is defined would be used for the other
setting, as a complement.  That way a coder could provide a minimal face
definition and still get something reasonable for other background modes.

This could obviously be made more sophisticated, but any such feature could be
an improvement, helping with the problem of coders being lazy and just defining
defaults for one background mode (e.g. light in my case; that is, I designed for
light but defined it as `t', meaning all).

----

Wrt face inheritance -

Faces are customizable - they are just like user options.  In particular, faces
are _not colors_ and faces are _not constants_.  Color names and RGB hex codes
are essentially constants (even if they can appear slightly different on
different systems etc.).

IMO, it makes sense for a face B to inherit from another face A _only_ when what
is wanted is that customization of A automatically is reflected in B.  When
doing this, we should _always_ expect and assume that A will be customized by
users.  This is true no matter how "basic" A is.

This is why (IMO) it does _not_ make sense in general for faces to inherit from
font-lock faces.  A user will want to customize a font-lock face in order to
affect the appearance of _font-locking_, typically in code.  It does not
generally make sense for a non-font-lock face to automatically become affected
by such customization.  Example: basing a Dired face on a font-lock face would
be perverted (IMO).

My guess is that people who are thinking that inheritance from a few (or even
many) "basic" faces (font-lock or others) is a good idea are not taking
customization of such basic faces by users into account.  IOW, they are not
considering them as _faces_, but rather as constants (e.g. as colors or color
combos).

There would be nothing wrong with defining some _constants_ from which faces
could inherit - not defface but something else that indicates the intention of
not being customized.  Nothing wrong with coming up with such "basic faces" that
would never be customized.

But what would that mean?  In this case what is important is not the _usage_ of
the face (it cannot be; that cannot be known), but just its attributes: colors
etc.  IOW, instead of a basic face `highlight' intended for highlighting we
would have basic faces whose names reflect only their appearance:
`red-foreground-bold-boxed' etc.

But though there would be nothing wrong with defining such constant faces, it
would be truly silly.  There is no sense defining such attribute combinations -
no sense defining (uncustomizable) faces for this.  We already have such
constants: the colors themselves (names and #RGB hex codes).  And numbers for
weights etc.  Defining combinations as constants makes little sense.

It is proper to base defface definitions on such constants, but not (in general)
on other faces.  The only time the latter is appropriate (IMO) is when we really
want customizing face A to affect face B which inherits from A.  You do not, I
think, want a Dired face to change just because a user tweaks a font-lock face
to make code comments stand out differently.

The real problem that I'm guessing motivates the (misguided) attempts to base
faces upon each other is that too often the default values of faces are not
defined well enough (see the Dired+ mea culpa above).  Too often too little
effort is devoted to defining the default attributes.

The other problem that has been mentioned is being able to apply different
themes and have the result be more or less reasonable across sets of faces.  I
think that this is not a fundamental problem but is only derivative from not
having good defaults.  Just having reasonable default values that cover both
light and dark backgrounds will go a long way toward eliminating this problem, I
expect.

In addition, tools that let users easily change whole sets of faces together,
incrementally, can help.  Do Re Mi offers some help in this way, and other such
tools can be envisaged.

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 - and even for defining themes.

I'd be interested in hearing more arguments in favor of faces inheriting from
faces (e.g. "basic" faces).  So far it all seems misguided to me, but perhaps
I'm missing a thing or two.  Please be clear about (a) the _problems_ you are
trying to solve this way, and (b) _how_ you think face inheritance can solve
them.