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

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tim Cross <theophilusx@gmail.com>
>> Date: Sun, 06 Mar 2022 05:38:55 +1100
>> Cc: emacs-devel <emacs-devel@gnu.org>
>> 
>> 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 don't see how inheritance would have made your problem smaller.  Are
> you assuming that the inheriting faces will never override the colors
> of their parent face?  If they do define their own colors (and most
> faces do), inheritance won't help you to change any significant part
> of the faces in fewer steps than you need to do now.
>
>> 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 don't think I understand the problem for which you are looking for a
> solution.  Would you please state it clearly?  Or at least could you
> describe what kind of customizations of each and every face do you
> have to do for your specific requirements?  Without a clear idea of
> the problem you are facing (pun intended), it is hard to say anything
> intelligent regarding possible solutions.

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.

My basic point is that I would prefer package authors use inheritance to
define the default value for new faces they add over the way too many
packages set the default value for faces they define. The issue is many
packages only do an extremely simplistic default face definition. 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. I suspect this is because doing a proper default face
setting which works across different environments and light or dark
themes can be complex. 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 and work out of the
box for more people.

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 OR inherit from a built-in face, but 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.

And yes, your correct that a face can be defined to inherit from another
face and also set the foreground or background and some do. However,
I've found that many don't and so setting the foreground/background of
the parent can provide good results and reduce the number of faces you
need to tweak individually.