Re: Status update of tree-sitter features

[Yuan Fu <casouri@gmail.com>]

> On Dec 28, 2022, at 4:34 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 29/12/2022 02:23, Yuan Fu wrote:
> 
>>>> function                every function identifier
>>> 
>>> The description makes it easy to mistake for function definitions as well. Whereas the place where this category is used is function/method calls, right? And perhaps some other references to methods inside the code where the language parser can distinguish those from property access, etc.
>>> 
>>> 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”). So there will be a bit of overlap between function, variable, and definition.
> 
> By "overlap", do you mean that font-lock rules should also have entries for variable/function definitions with category 'variable'/'function'?
> 
> In case somebody removes 'definition' from their list of enabled features but keeps 'variable' and 'function' there?

Basically, if you enable definition alone, you get highlight for function/variable/class definition. If you enable function/variable alone, you get highlight for all occurrence of function/variable identifiers, which would includ what definition highlights. Definition can be seen as the union of subsets of function & variable feature.

> 
>>>> variable                every variable identifier
>>> 
>>> 'variable', so far, seems like the least useful. When enabled, it lights up every bit of text that remained from other matchers -- because identifier are everywhere.
>> Yes, but apparently people want it ;-)
> 
> Well, if they really do.
> 
> I figured that people who added this maybe haven't tested this thoroughly. And that maybe they expected the effect of that "local variables highlights" feature that some editors showcase already.

The purpose of the standard list is to regulate features, so if a major mode wants to support a feature in the list, it uses the definition and name from that list (rather than creating a feature with same definition but different name, or same name but different definition). If a major mode really want variable feature, they can add it, if not, they don’t have to.

> 
>>> There is this more advanced prior art for highlighting variables, by tracking the scopes using custom annotations, see locals.scm here:
>>> 
>>> https://tree-sitter.github.io/tree-sitter/syntax-highlighting#local-variables
>>> 
>>> What's displayed under "Result" would be really handy to have in Ruby.
>>> 
>>> It's nothing urgent, of course. Maybe for Emacs 30?
>> Yeah, this requires some non-trivial addition to the current fontification code.
> 
> Thank you.
> 
>>> For Emacs 29, though, I would discourage the use of 'variable’.
>> It’s on level 4, meaning not enabled by default, so I think it’s fine.
> 
> Fair enough. If someone wants function/property but not variable, they could fine-tune the list.

Right. All the features in level 4 are pretty over-the-top IMO, so simply bumping to level 4 and enable everything is probably not the way to go.

Yuan