Re: Status update of tree-sitter features

[Dmitry Gutov <dgutov@yandex.ru>]

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?

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

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

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?

For Emacs 29, though, I would discourage the use of 'variable'.

Thanks,
Dmitry.