RE: [External] : Re: Defaulting faces to inherit deemed harmful [was: Stealing a default face from a non-ELPA package]

[Drew Adams <drew.adams@oracle.com>]

> Well I don't have a problem per se. I was mainly responding to Drew's
> claim that defining faces to use inheritance was harmful.

To be fair (in spite of the abbreviated and
tongue-in-cheek Subject line) what I really
suggested was _less predefining_ of faces
with inheritance.

I responded to your post saying you would
prefer that "_more_ packages would define
their faces in terms of inheritance from
standard/built-in faces."  Where you would
like more to do that, I'd like fewer to.

> The issue is many packages only do an extremely simplistic
> default face definition.

If "simplistic" means not imposing inheritance
by default, then good for them.  In general,
it's better not to couple a face's default
definition to another face's definition (for
the reasons I gave).

> For example, just setting the foreground to a colour which looks good for
> the theme they are using and not using the facilities available to set
> the default based on whether the user is running in a GUI frame, inside
> a terminal, on the GNU Linux console or whether they are using a dark
> or light theme.

That's something entirely different from 
whether to inject inheritance into a face's
default definition.

I happen to agree with everything in your last
paragraph.  It's just unrelated to whether it's
good or bad to define face X as inheriting from
face Y by default.

Except that of course any decision to inherit
from another face by default should involve
attention to the things you mention.  The same
attention should be paid when considering all
face attributes.

> I suspect this is because doing a proper default face
> setting which works across different environments and light or dark
> themes can be complex.

Yes, I think so.  The same problem exists for
defining the types of defcustoms.  Many, many
(most?) could stand to be refined a bit, to be
more useful.

> If on the other hand, their default just
> inherits from one of the built-in faces which typically do take 
> these factors into account, it would provide increased consistency

I suppose that's true.  But that's another
lazy way out - like what you decry - even if
it's more likely not to be flaky.

> So basically, my argument is EITHER define the face so that the default
> works well regardless of whether the user is running in GUI, terminal,
> console or a light/dark theme

Just leave it at that.  The message should be
to just take face attributes seriously when
defining defaults.  Including :inherit.

> don't just make the default a simple :foreground "xxxx", which will only work
> well if the user happens to use a similar environment and light or dark
> theme as the author.

It's really not that hard to choose a default
color for dark if you only use light, or vice
versa.

It's best of course to test/try both.  But even
just using a color complement for the opposite
`background-mode' can be pretty good.  (And it's
simple to obtain: `color-complement-hex'.)