[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recent updates to tree-sitter branch
From: |
Yuan Fu |
Subject: |
Re: Recent updates to tree-sitter branch |
Date: |
Mon, 26 Sep 2022 01:35:59 -0700 |
> 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
Re: Recent updates to tree-sitter branch, Aurélien Aptel, 2022/09/29