Re: More font-lock faces for tree-sitter

[Randy Taylor]

Stefan Kangas <stefankangas@gmail.com> writes:

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

Any benefit? That depends on who you ask. I already make use of all of
these, have for quite some time, and would be very sad without them. I
was planning to contribute C and C++ syntax highlighting support for
tree-sitter (and maybe more languages if time permits), and was hoping
to use these faces.

Without these faces I will need to define them myself in my own config
and use my own queries, which is really annoying IMO.

The big benefit is that we are empowering users to customize syntax
highlighting at a more fine-grained level to their own liking, and I
think that's a good thing.

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

I don't see the problem with that. Theme developers will make the
themes that they want (and I for one am a fan of angry fruit
salad). And users can customize those faces themselves anyway, so
what's the problem?

Besides, theme developers can already do that can't they?

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

We already know how tree-sitter is used in practice.

neovim has had tree-sitter support for quite some time now and
supports many more than these faces. They even go down to the level of
letting you customize loops and conditionals differently (which I'm
not proposing - like you say, we can wait and see for that stuff).

The same applies to the Emacs tree-sitter dynamic module
implementation (which has been around since 2020), which I and many
others have been using since it came out.

I agree that we should be careful about which faces we add, but I
think the faces that I listed are pretty general and apply to most
languages, so it makes sense to include them.