[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recent updates to tree-sitter branch
From: |
Ihor Radchenko |
Subject: |
Re: Recent updates to tree-sitter branch |
Date: |
Sun, 02 Oct 2022 15:33:44 +0800 |
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).
I do not insist on my idea being actually used, but wanted to leave a
data point to be considered.
> 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?
--
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