Re: Recent updates to tree-sitter branch

[Ihor Radchenko <yantar92@gmail.com>]

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

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92