Re: Status update of tree-sitter features

[Yuan Fu]

> 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