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

[Theodor Thornhill <theo@thornhill.no>]

Hi and sorry to interject,

>> compile and run multiple queries.
>
> 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.  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.

The `treesit-font-lock-fontify-region` is the culprit here, and
could look up in an easier way, I think.

> 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.  I don't think that
parsing a c file with go queries is at all interesting, because the
parser would return errors all over and is clearly not how it is
supposed to be used.

> But if it turns out that a query doesn't depend on the buffer
> contents, I think this is a moot point, and the major mode could
> compile the query just once when its first loaded.
>

Agreed.

Theodor