Re: Status update of tree-sitter features

[Yuan Fu]

> On Dec 28, 2022, at 3:27 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> Hi Yuan,
> 
> I'm late to the party, so apologies if any of the following has been 
> discussed before.
> 
> On 28/12/2022 11:44, Yuan Fu wrote:
> 
>> Here is the list, for your reference. Among all the features, I think 
>> assignment is “nice to have”, it’s fine to leave it out if there isn’t 
>> enough time. Same goes for key: it may or may not apply to a language.
>> Basic tokens:
>> delimiter       ,.;      (delimit things)
>> operator        == != || (produces a value)
>> bracket         []{}()
>> misc-punctuation
>> constant        true, false, null
>> number
>> keyword
>> comment         (includes doc-comments)
>> string          (includes chars and docstrings)
>> string-interpolation    f"text {variable}"
>> escape-sequence         "\n\t\\"
>> 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. 

> 
>> type                    every type identifier
>> property                a.b  <--- highlight b
> 
> Do we think it's a good idea to have 'property' in the default highlighting? 
> IIUC the default level is 3.
> 
> Code like foo.bar is easy to understand at a glance, so it seems like it'll 
> lead to a lot of repeated highlights. If 'function' (or 'funcall') is a level 
> 4, maybe 'property' should be there too?

Ah yes property should be level 4, along with function and variable.

> 
> > 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 ;-)

> 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.

> 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.