Re: Status update of tree-sitter features

[Yuan Fu <casouri@gmail.com>]

> On Dec 30, 2022, at 3:41 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 30/12/2022 13:16, Yuan Fu wrote:
> 
>>> Yes, but is that classification useful enough to justify the duplication in the font-lock rules' definitions?
>>> 
>>> FWIW, I "broke" python-ts-mode in 8503b370be1, according to this definition. Sorry?
>>> 
>>> But what do we get by this particular classification?
>>> 
>>> The user will be able to disable 'definitions' and still have all function definitions highlighted? But not, say, variable definitions?
>>> 
>>> That doesn't strike me as particularly more useful than e.g. disabling 'definitions' and having all function references highlighted (but not definitions). Which we would make possible by limiting 'function' to non-definitions.
>> Right now you can choose to highlight:
>> 1. Only definition identifiers, be it function, variable, class, etc
>> 2. All function identifiers
>> 3. All variable identifiers
>> There could be better features, but the existing ones still have their merits. If you want a feature that highlights only funcalls, maybe we can add them, if there are enough time & interest.
> 
> I'm mostly worried about having to duplicate font-lock rules between categories at this point. It just looks impractical to me.

I’d say we judge it case-by-case. In this case it seems fine to me.

> 
>>> Okay, I also have a different, somewhat related question.
>>> 
>>> Certain languages have a special syntax for "variables".
>>> 
>>> Ruby has @instance_variable and $global_variable -- the @ and $ are used both during assignment and for later reference.
>>> 
>>> Perl has $var and @array_var.
>>> 
>>> PHP has $local_var.
>>> 
>>> Up until now we've highlighted those with font-lock-variable-name-face. Except for @array_var in Perl, which has separate derived face. Either way, we did highlight them.
>>> 
>>> What category should we use for them in ts-based modes? If it's 'variable', then won't be highlighted by default.
>>> 
>>> If 'variable' matchers in other existing ts modes didn't include all identifiers everywhere, we could put 'variable' into level 3.
>>> 
>>> Or we could add a separate category for all those, I guess.
>> If a major mode thinks highlighting all variables is the best default behavior, it can support the variable feature and put it at level 3. The standard list is just a guideline.
> 
> So you're suggesting ruby-ts-mode changes treesit-font-lock-feature-list locally, and either moves 'variable' to a lower level, or adds a new category for said vars.
> 
> We can do that, thank you.

Yeah, ultimately it’s your judgement.

Yuan