Re: Status update of tree-sitter features

[Yuan Fu]

> 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