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

[Drew Adams]

> 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!

Eli pointed out that faces that inherit can also set other
face attributes, specializing their the appearance and so
forcing you to customize them individually as well.

Beyond that important observation, I think that what
you (Tim) have said - which is useful & valid - is really
an argument for Customize to add the ability to quickly &
easily choose a selection of faces and apply a given
setting to all of them at once.

That's totally separate, conceptually - and potentially in
practice - from inheritance by default (i.e., predefined).

Telling Emacs to inherit each of a set of faces from some
face would then be a simple operation.

Likewise, doing that to define multiple inheritance levels,
using different face groups and different faces to inherit
from (including from faces that inherit from others etc.).

For the Customize UI to define such an operation to apply
a setting to a set of faces is a nice-to-have (but truly
welcome) addition.  But a first start would be to define
a command that does that.

The command could be general - any face attributes, not
just :inherit.  And multiple attributes at the same time.

It would need to let you (1) choose the faces to act on
(to set their attributes), (2) choose the attributes to
set, and (3) choose the new attribute values (e.g., for
attribute :inherit, choose which face to inherit from).

To choose multiple thingies, a command can loop over
minibuffer reads, or use `completing-read-multiple', or
use some completion framework that lets you easily
define a set of things using completion matching etc. 

With various completion/selection frameworks this would
be particularly easy to provide - and to use.  With
vanilla Emacs it might be a bit more cumbersome, but
something reasonable could be done.

> I'm sure some will suggest the problem is due to too 
> many packages defining faces when not necessary.

Not I.  Quite the contrary.  I wish more libraries
would consider defining more faces, for specific
uses/contexts.

E.g., my Info+ defines 26 faces; Bookmark+ defines 29;
Dired+ defines 28; Icicles defines 37.

> 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.

I'm not surprised.  And I don't see it as bad/worse but
good/normal/useful, in general.

If more faces are defined for more, finer-grained contexts,
a user can always coalesce any groups of them to look the
same (modulo the bother you raised in doing that, which I
addressed above).

But consider the other direction: If some library defines
only very coarse-grained highlighting, i.e., it doesn't
let you distinguish things on a fine scale, then you're
out of luck to move in a finer-grained direction.  Other
than resorting to Elisp and tweaking the library's use of
faces (e.g. its font-locking).

It's easier to lump existing distinctions than to split
them to provide more distinctions.  Much easier.