Re: Status update of tree-sitter features

["Jostein Kjønigsen" <jostein@secure.kjonigsen.net>]

Hey everyone.

Sorry for being late to the party. As far as I can tell, there seems to 
be mostly consensus on the overall picture, while some different 
opinions wrt to what to actually standardize.

On 29.12.2022 04:28, Stefan Monnier wrote:
>>> If it's only about calls, maybe call this category funcall?
>> Function, property and variable are for every occurrence of them (the touted
>> “consistent highlighting”).
> In my own use, the difference between a definition and a use is more
> important than the difference between a variable name and a method name.
> I'm not fundamentally opposed to highlighting funcalls, but it is
> indispensable that funcalls get a different face from
> function definitions.
>
>
>          Stefan
>
I know that some people prefer "sparse" syntax-highlighting, while 
others prefer more "complete" highlighting. Personally, I value being 
able to see function invocations, and love how tree-sitter makes that 
easy to highlight.

As long as we have ways to accommodate both needs ("fruit salad" vs more 
sparse fontification) I'm going to be happy, and we kind of already have 
that through font-lock levels in the modes already.

That said, some of the tree-sitter based major modes (half? most?) 
currently highlight function-invocations on level 3. If we are to make 
everyone happy, we need to make changes to that, and move that to 4.

Which leads me to my main point here.

Emacs 29 release is near. We should seriously limit the amount of 
changes we apply in order to fix the things we need.

Deciding at this point to rework all the features, which features we 
should have, how they can be enabled/disabled, and what 
enabling/disabling those should entail in practice... That's essentially 
suggestion we rewrite all those tree-sitter-based major-modes.

I think a much more realistic strategy at this point is:

- to aim for what concrete things should be fontified at level 3 and 4 
(default vs max). We already know 1 thing we want to change here.

- ensure the major-modes adhere to this with a minimum of changes in the 
existing code.

- and most importantly: leave the discussion about adding the ability 
for users to enable/disable specific features, and how that should work 
in practice (overlap, presedence, etc) for Emacs 30.

Doing so would leave the new tree-sitter based major-modes pretty much 
functionally on par with existing major-modes (or better, more 
accurate), and it buys us a full, new release-period to figure out how 
we can leverage tree-sitter to give end-users better customization 
options, instead of coming up with ideas at the verge of release, 
without having time to let those ideas mature.

This will end up being an API of sorts, and from my experience you don't 
want to rush those.

My 2 cents.

--
Jostein