Re: More font-lock faces for tree-sitter

[Stefan Kangas]

Randy Taylor <dev@rjt.dev> writes:

> Here are some that I had in mind:
> - font-lock-escape-face
> - For escape characters in strings.
> - font-lock-property-face
> - Usually an object property, like a member in a class or struct.
> - font-lock-punctuation-face
> - In addition, we could get even more specific: 
> font-lock-punctuation-{delimiter, bracket, special}
> - font-lock-number-face
> - font-lock-operator-face

I'm not sure we should rush to add a ton of new faces, just because we
can.  Language modes can still add new faces themselves, so the
discussion here is about which set of default faces we should have.

For example, is there any benefit to adding `font-lock-number-face'?
I don't think I've seen many language modes doing that so far.  Is there
a high demand for it?  Is there a big benefit?  Personally, I don't feel
confident answering that.

Adding a face, especially a default one, is an implicit invitation to
theme developers to use it.  If we add too many faces, we risk, in the
worst case, seeing a proliferation of angry fruit salad.

This feature is not even merged to master yet, so perhaps we should take
a more careful approach:

Time and experience will let us see how tree-sitter is used in practice.
If many language modes end up adding a face for something, we can say:
okay, now we have proof that this highlighting is generally useful.
Let's add a corresponding built-in face that everyone can inherit from.

To my mind, doing it the other way around risks putting the cart before
the horse.  Just my two cents.