Re: Recent updates to tree-sitter branch

[Yuan Fu]

> On Sep 24, 2022, at 11:17 PM, Ihor Radchenko <yantar92@gmail.com> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>> 2. Although treesit-font-lock-settings didn’t change, 
>> treesit-font-lock-defaults is abandoned. You are also now supposed to use 
>> treesit-font-lock-rules to build the queries and set it to 
>> treesit-font-lock-settings. It is much cleaner than setting 
>> treesit-font-lock-settings manually.
> 
> I am not sure if it has been discussed, but may I ask a few questions
> regarding treesit-font-lock-rules.
> 
> If my understanding is correct, the font-lock rules are somewhat
> equivalent font-lock-keywords, but much more limited.
> 
> font-lock-keywords elements can have a form of
> 
> MATCHER
> (MATCHER . SUBEXP)
> (MATCHER . FACENAME)
> (MATCHER . HIGHLIGHT)
> (MATCHER HIGHLIGHT ...)
> (eval . FORM)
> 
> where MATCHER is either a regexp or a function.
> 
> treesit-font-lock-rules rules take a form of
> (MATCHER FACENAME) or (MATCHER FUNCTION)
> 
> where MATCHER can only be a query.
> 
> Is there any reason why MATCHER in treesit-font-lock-rules cannot be a
> function with access to the fontified node?

Hmm, I’m not sure what do you mean. The whole thing passed to 
treesit-font-lock-rules is a single query, and we can’t really change the query 
syntax, that’s defined by tree-sitter. Basically in a query you have patterns 
paired with capture names, if the pattern matches to a node, that node is 
returned with corresponding capture name tagged on it. For font-lock, we just 
use face names as capture names, and when a query returns captured nodes, 
fontify the node with its capture name, aka a face (or a function).

> It will allow more flexible
> fontification, when programmatic query can be used to decide the
> fontification.
> 
> Further, can OVERRIDE FLAG of the MATCH-HIGHLIGHT as in
> font-lock-keywords be supported?
> 
>   "If OVERRIDE is t, existing fontification can be overwritten. If
>    keep, only parts not already fontified are highlighted. If prepend or
>    append, existing fontification is merged with the new, in which the new
>    or existing fontification, respectively, takes precedence.”

I can do that, but would it be really useful? Unlike regex font-lock which is 
used for so many different things, tree-sitter font-lock is, IMO, only used to 
apply a base layer of language-specific highlight. How would one use the 
override feature in this scenario?

Yuan