Re: Recent updates to tree-sitter branch

[Ihor Radchenko <yantar92@gmail.com>]

Yuan Fu <casouri@gmail.com> writes:

>> What I am asking is an extra dynamic condition in addition to the query.
>> For example:
>> 1. Only apply FACENAME for nodes matching QUERY, but only when Elisp
>>   variable is non-nil
>> 
>> 2. Only apply FACENAME for nodes matching QUERY, which are in the second
>>   half of the buffer
>> 
>> 3. Only apply FACENAME for notes matching QUERY, which also have a field
>>   matching a dynamically assigned regexp.
>> 
>> Essentially any condition that is not covered by the QUERY, but can be
>> checked in Elisp given that node object is passed to the test function.
>
> These can be achieved by using a function, no? You do need to declare global functions for them, but it shouldn’t be a problem. Besides, as I said, the query syntax is not something we can change. The freedom we have is how do we use the capture names. We can’t extend the query with arbitrary lisp.

Will the currently matched node be passed to the function? Or should the
function run yet another query to determine the node it was called on?

>>>> 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?
>> 
>> For example, consider a function definition with docstring field.
>> Imagine that you want the function definition to have gray background,
>> but the docstring to have yellow background. OVERRIDE t is how this is
>> usually implemented in font-lock-keywords.
>
> The pattern that comes after will override patterns that come before. By the nature of parse trees, for any node A and another smaller node B, B is either completely contained in A or completely outside A. So I think the override relationship is enough.

OVERRIDE can also be 'prepend or 'append to combine faces from multiple
nodes.

Also, OVERRIDE nil will not apply fontification on the already fontified
parts of the region. Note that the parent node might only fontify
fraction of the text inside the child node. The parts not yet fontified
can make use of OVERRIDE nil.

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