Re: Update on tree-sitter structure navigation

[Yuan Fu]

> On Sep 6, 2023, at 4:57 AM, Ihor Radchenko <yantar92@posteo.net> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>> I think that both NODE types and attributes can be standardized.
>> 
>> If we come up with a thing-at-point interface that provides more information 
>> than the current (BEG . END), tree-sitter surely can support it as a 
>> backend. Just need SomeOne to come up with it :-) But I don’t see how this 
>> interface can support semantic information like arglist of a defun, or type 
>> of a declaration—these things are not universal to all “nodes”.
> 
> For example, consider something like
> 
> (thing-slot 'arglist (thing-at-point 'defun)) ; => (ARGLIST_BEG . ARGLIST_END)
> (thing-slot 'arglist (thing-at-point 'variable)) ; => nil
> 

Yeah, that makes sense.

>>>> - I can’t think of a good way to integrate tree-sitter queries with
>>>> the navigation functions we have right now. Most importantly,
>>>> tree-sitter query always search top-down, and you can’t limit the
>>>> depth it searches. OTOH, our navigation functions work by traversing
>>>> the tree node-to-node.
>>> 
>>> May you elaborate about the difficulties you encountered?
>> 
>> Ideally I’d like to pass a query and a node to treesit-node-match-p, which 
>> returns t if the query matches the node. But queries don’t work like that. 
>> They search the node and returns all the matches within that node, which 
>> could be potentially wasteful.
> 
> Isn't ts_query_cursor_next_match only searching a single match?

Seems so, that’s good. But there’s no guarantee that the first match with be 
the top node, even thought implementation-wise, I think that’s probably the 
case. Maybe we can ask tree-sitter developer to add such a promise.

>>>> - Isolated ranges. For many embedded languages, each blocks should be 
>>>> independent from another, but currently all the embedded blocks are 
>>>> connected together and parsed by a single parser. We probably need to 
>>>> spawn a parser for each block. I’ll probably work on this one next.
>>> 
>>> Do you mean that a single parser sees subsequent block as a continuation
>>> of the previous?
>> 
>> Exactly.
> 
> Then, I can see cases when we do and also when we do _not_ want separate
> parsers for different blocks. For example, literate programming often
> uses other language blocks that are intended to be continuous.

Surprise, I added support for local parsers. Major mode authors can choose 
between global and local parsers.

Yuan