Re: Tree-sitter integration on feature/tree-sitter

[Theodor Thornhill <theo@thornhill.no>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: casouri@gmail.com, emacs-devel@gnu.org
>> Date: Fri, 13 May 2022 10:04:03 +0200
>> 
>> > Is it true that there's just one query for each PL mode, and it is
>> > fixed (doesn't change) and doesn't depend on the buffer contents in
>> > any way?  If that is true, the major mode could compile the query
>> > whenever it is initialized, and then reuse it in every buffer that is
>> > under that major mode.
>> >
>> 
>> Yes, for indentation and font locking, this is correct.  I'd think that
>> it'll be enough to compile on mode init, and just reuse it.  For some
>> hypothetical other uses, such as searching and replacing, we would need
>> to be more dynamic, but that won't have the performance issues that font
>> locking typically has.
>
> Right.
>
>> Why not use the same idea as the `eglot-managed-mode`, where if the
>> file fulfills some predicate, we choose to treat them all as equals.
>> Thus we only need to compile/read/use the queries once, and can
>> simply lookup what we need.
>
> We can do something like that if needed.  But I don't necessarily see
> the need yet.  When will we need this, if a major mode compiles the
> query once when it is first turned on in some buffer?
>

Thinking more about that, I don't think we do need it, considering it
will run as a major mode. I guess it may be interesting should we want
to supply tree sitter functionality as minor modes. Let's say that some
major mode author doesn't want to integrate with tree sitter, and won't
accept such a patch.  Then we could still allow overriding font locking
of that mode given the proper means to do so.  Another case is for minor
modes such as paredit and the likes.  It could support advanced editing
facilities without being part of the main tree sitter major mode
integration.  Then it would make sense to have a tree-sitter-minor mode
thing.  But this is all just ideas from the top of my head, and not
necessarily anything worth considering for the first implementation of
tree sitter.

>> > There isn't any (IIUC what you are asking).  Fontification is a
>> > feature of interactive sessions, and is basically meaningless without
>> > normal redisplay.
>> >
>> 
>> An ok benchmark would be using C-n rather than C-v, because that seems
>> to trigger more performance issues in my daily use.
>
> We should benchmark both, because both are important.
Agreed