Re: Update on tree-sitter structure navigation

[Ihor Radchenko]

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

>>> - 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?

>>> - Major mode fallback/inheritance, this has been discussed many times, no 
>>> good solution emerged.
>> 
>> I think that integration of tree-sitter with navigation functions might
>> be a step towards solving this problem. If common Emacs commands can
>> automatically choose between tree-sitter and classic implementations, it
>> might become easier to unify foo-ts-mode with foo-mode.
>
> Unifying tree-sitter and non-tree-sitter modes creates many problems. I’m 
> rather thinking about some way to share some configuration between two modes. 
> We’ve had many discussions before with no fruitful conclusion.

Any chance you have links to these discussions?

>>> - 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.

-- 
Ihor Radchenko // yantar92,
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>