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

[Tim Cross <theophilusx@gmail.com>]

Drew Adams <drew.adams@oracle.com> writes:

>> Personally, I wish more packages would define their
>> faces in terms of inheritance from standard/built-in
>> faces. This would mean a user could tweak the built-in
>> faces to suit their preferences and the additional
>> packages would inherit those tweaks without needing
>> to be done individually.
>
> Personally, I wish fewer packages, and default
> Emacs itself, would define _fewer_ faces as
> inheriting from other, standard/built-in faces -
> in particular from font-lock faces.
> ___
>
> tl;dr:
> I expect that my opinion on this is a tiny minority
> one.  I express it anyway, hoping it might open one
> or two eyes or kindle a second thought here & there.
> ___
>
> _Users_ can always do what you say: customize faces
> to inherit from some face they want as parent.  And
> they can do that at multiple levels: inheritance
> hierarchy as deep or broad as you like - turtles
> all the way...).
> ___
>
> Font-lock faces, in particular, are defined to be
> appropriate, by default, for particular _purposes_
> (contexts) - e.g. comments.  Inheriting from them
> willy nilly for faces that have nothing to do with
> those purposes (e.g. non-code modes don't have
> comments) creates unnecessary coupling.
>
> The only face that has no specific purpose/context
> is face `default'.  And that's as it should be.
> In effect, all faces inherit from `default' (in
> addition to having their own particularities).
> ___
>
> Inheritance can be invisible at first sight, when
> trying to figure out why a face looks as it does.
>
> Inheriting by default is a bludgeon.  That blunt
> club is often touted as the _reason_ for built-in
> face inheritance by default:
>
>> without needing to be done individually
>
> A false problem, IMO.
>
> 1. Customizing a face _should_ in general be an
>    individual choice, taking _context_/purpose
>    into consideration.  (It's a similar decision
>    to that of defining its default appearance.)
>
> 2. Nothing prevents customizing a face to inherit
>    from another, including from standard/built-in
>    faces.  It's _not at all difficult_ to do.
> ___
>
> Inheriting by default has almost the same negative
> effect as defining a face to have, by default, the
> same appearance as face `default' (a practice that
> `emacs -Q' used to embrace, and perhaps still does
> here and there): You can't tell at a glance that
> there's a separate/different face there.
>
> Far better to use a different default appearance,
> even if perhaps "ugly", so that users immediately
> see that there's a separate face there that they
> can customize to their liking.
>
> The best way to introduce users to the fact that
> they can easily customize faces is to let faces
> stand out individually, by default.
> ___
>
> I don't mean that each face needs a different
> default definition.
>
> I mean only that, other things being equal,
> identical appearance works against recognizing
> the presence of a different face.
>
> What appearance to give a given face by default
> is always a judgment call.  I mean only to add
> this consideration to such a judgment, as one
> more consideration, perhaps too often overlooked
> in a zeal to concentrate face default appearance
> with predefined inheritance.
> ___
>
> One place _to_ perhaps use face inheritance by
> default is in a theme.
>
> And a library can similarly have some of its
> faces inherit from some of _its_ other faces -
> the `vc-*' faces inherit from `vc-state-base',
> for example (with the tradeoff mentioned above:
> lack of immediate recognition).  
>
> A priori, most other uses of predefined
> inheritance are  likely unwise/unhelpful, IMO. 

The big use case your argument overlooks is the one I'm forced to deal
with all the time. I have very specific requirements for face colours
because of a vision impairment. Emacs is a constant frustration for me
because of the number of faces which are defined. For example,
list-display-faces shows over 1030 faces on my system!

Without inheritance, this means I have to customise a majority of those
faces. I have also yet to find a theme which handles this well, though
the modus themes are pretty good and life has gotten better since all
the fine work put into those themes.

The issue of inheritance based on faces defined for a different purpose
is not a big issue and could be largely addressed by defining a good set
of 'base' faces with appropriate names. However, I find this a lesser
problem than the number of faces which are poorly defined and only work
well if you are running in a GUI frame or use a light theme or use a
terminal with 256 colour support etc. 

I also think the issue of inheritance causing problems because users
don't realise a face inherits from another face is overstated.
Inheritance is just another attribute in the face definition and is as
clear as any other attribute setting. Furthermore, if inheritance was
used more, users would become more aware of it and would deal with it
appropriately.

Having over 1000 separate face definitions seems insane at one level,
but I guess it does allow the ability for users to have ultimate
customisation. However, if we are going to have so many faces, there
really needs to be a mechanism which allows customisation which avoids
having to have 1000 set-face-* or a huge set custom face block in your
init file. This doesn't have to be via inheritance, but that seems to be
a workable solution until someone suggests something better.

I'm sure some will suggest the problem is due to too many packages
defining faces when not necessary. That may be true. However, I see lots
of people requesting distinct faces in many of the packages I follow, so
don't see that getting any better - in fact, I expect it will get worse
as more great useful packages are added to the Emacs ecosystem.