Re: Automatic face setting based on contrast?

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tim Cross <theophilusx@gmail.com>
>> Date: Fri, 08 Oct 2021 11:49:06 +1100
>> 
>> Over the years, I've seen a considerable growth in the number of faces
>> defined, which has made consistent definitions of themes somewhat
>> challenging. Running M-x list-display-faces on my system shows over 1100
>> face definitions, which seems excessive.
>
> In "emacs -Q", I see only 114 faces in that display.
>

which makes me wonder why so many packages feel it necessary to add new
faces rather than just leverage off the 'default' faces. Would not be as
challenging if all those additional faces defaulted to inherit from one
of the 114 'default' faces, but unfortunately, many don't.


>> While many of these do use
>> inheritance, many don't. This is unfortunate. It would be great if all
>> modes which define faces by default inherit from one of the semantic
>> font lock faces, allowing basic theme definitions to be possible by just
>> tweaking the much smaller number of semantic faces and leaving tweaking
>> of mode specific derived faces to the user when desired.
>
> I think tweaking 100+ faces is not much easier than tweaking 1000.
> Both border on the impractical.
>

Agreed. However, not all of those 114 are 'semantic' faces. If the
default for each non-semantic face was to inherit from the semantic
faces, then most themes would be able to be defined via setting the
handful of semantic faces and leave more specific customization to the
end user who want to tweak the them in some manner.

>> It would also be useful if there was some way of listing the defined
>> faces which showed which face they are derived/inherited from to make it
>> easier to see exactly what would be affected if you modify the 'parent'
>> face and which faces are not defined to inherit from one of the semantic
>> faces (and could be a possible candidate for redefining to inherit from
>> a semantic face).
>
> That sounds like a simple Grep job to me.
>

Hmm, not sure it is that simple given grep is line based and face
definitions can be spread over multiple lines. However, once you have
gathered the list of faces, it wouldn't be too hard to iterate over them
to extract which ones are inherited.

What I was thinking of was a display which would show the inheritance
hierarchy, possibly in some sort of tree form to give an overview so
that you could not just tell which faces inherited, but where they
inherited from.

In some respects, the ability to add new faces is possibly a little too
easy and has encouraged an over proliferation of faces. This makes
consistent theming much harder than necessary.  

> Eventually, I don't think there's a good solution to color contrast
> that relies on manual tweaking of the faces.

I'm not convinced there is a good automatic solution which won't also
need some manual tweaking, especially given how quickly the number of
faces blows out once you add some additional packages. While automatic
contrast setting can help, manual tweaking will still be necessary.
Consistent use of inheritance from the core semantic faces would make
this easier.

One challenge with automatic contrast setting is that it has no way to
take aesthetics into account - you can get high contrast colours which
are simply unappealing. This is still better than the current situation
when you unexpectedly come across a face which is unreadable because it
has not been set to a suitable contrast for the current theme.  This
would be less of an issue if all these additional faces inherited from
the core semantic face by default. The code to ensure adequate contrast
would then only need to consider those semantic faces.