[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: |
Sun, 2 Oct 2022 15:54:54 -0700 |
> On Oct 2, 2022, at 12:33 AM, Ihor Radchenko <yantar92@gmail.com> wrote:
>
> Yuan Fu <casouri@gmail.com> writes:
>
>>> I disagree. The current default in font-lock-keywords is not to
>>> override. If programmatic font-lock behaves differently, it will be
>>> confusing.
>>
>> I think the tree-sitter queries are different enough from font-lock keywords
>> that it will not bring confusion. Further more, default to override should
>> make things easier, especially to delicate things like string interpolation,
>> or other nested constructs, where tree-sitter shines. By default, if the
>> to-be-fontified region has any existing face, the whole fontification is
>> given up instead of filling in new fontification. That would be IMO
>> confusing because user would think the match failed.
>
> I do agree that it may be confusing. Yet, it is how the default
> fontification works. I do not think that tree-sitter matching is
> conceptually different compared to regexp matching. (And this particular
> area is not even limited to tree-sitter, AFAIU).
It’s not conceptually different from regex matching, but the tooling is
different enough that may bear to be different in some aspect without creating
confusion. But I understand that this is purely subjective.
I cc’ed Stefan. Maybe he has more educated opinions about this. (Aka could you
make a decision please because I couldn’t.)
>
> I do not insist on my idea being actually used, but wanted to leave a
> data point to be considered.
Thanks. I don’t think my opinion is definitely better, either. Both sides seems
reasonable to me. I hope that through discussion we can explore the topic
throughly.
>
>> Also bear in mind that the override flag can only be applied to the whole
>> query, rather than individual captured nodes.
>
> How does it change anything? I may be misunderstanding something---can
> you provide some illustrative example clarifying whole query vs.
> individual notes?
What I meant is that, for font-lock-keywords, one can set override flag for
each individual match:
(string-regex font-lock-string-face t)
(function-name-regexp font-lock-function-name-face nil)
(class-name-regexp font-lock-type-face t)
...
But for tree-sitter, a query contains many matches and the flag is set for the
query. So if I want to use different override flag for different matches, I
need to split them into two queries:
(treesit-font-lock-rules
:language 'python
:override 'append
'((string) @python--treesit-fontify-string
((string) @font-lock-doc-face
(:match "^\"\"\"" @font-lock-doc-face))
(interpolation (identifier) @font-lock-variable-name-face))
:language 'python
:override nil
'((function_definition
name: (identifier) @font-lock-function-name-face)
(class_definition
name: (identifier) @font-lock-type-face)
;; Comment and string.
(comment) @font-lock-comment-face))
That means if we use override=nil as default, it is very likely that users need
to explicitly set override to t for the whole query, or split the query into
separate parts. Nothing serious, but it seems less convenient.
A real use-case for override is how I fontified Python strings above. I have
three matches for (1) all strings (2) docstrings (3) variable names in string
interpolations. IMO it’s intuitive and convenient for later more specific
matches to override earlier more general matches.
Yuan