From: Yuan Fu <casouri@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: emacs-devel <emacs-devel@gnu.org>,
"Danny Freeman" <danny@dfreeman.email>,
"Theodor Thornhill" <theo@thornhill.no>,
"Jostein Kjønigsen" <jostein@secure.kjonigsen.net>,
"Randy Taylor" <dev@rjt.dev>,
"Wilhelm Kirschbaum" <wkirschbaum@gmail.com>,
"Perry Smith" <pedz@easesoftware.com>,
"Dmitry Gutov" <dgutov@yandex.ru>
Subject: Re: Update on tree-sitter structure navigation
Date: Thu, 7 Sep 2023 18:06:49 -0700 [thread overview]
Message-ID: <8A2B8A2E-FC24-401B-ACF8-688F2B157FB6@gmail.com> (raw)
In-Reply-To: <87msxzsee1.fsf@localhost>
> 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
next prev parent reply other threads:[~2023-09-08 1:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-02 5:01 Update on tree-sitter structure navigation Yuan Fu
2023-09-02 6:52 ` Ihor Radchenko
2023-09-02 8:50 ` Hugo Thunnissen
2023-09-02 22:12 ` Yuan Fu
2023-09-06 11:37 ` Ihor Radchenko
2023-09-08 0:59 ` Yuan Fu
2023-09-02 22:09 ` Yuan Fu
2023-09-06 11:57 ` Ihor Radchenko
2023-09-06 12:58 ` Eli Zaretskii
2023-09-08 12:03 ` Ihor Radchenko
2023-09-08 13:08 ` Eli Zaretskii
2023-09-08 1:06 ` Yuan Fu [this message]
2023-09-08 9:09 ` Ihor Radchenko
2023-09-08 16:46 ` Yuan Fu
2023-09-03 0:56 ` Dmitry Gutov
2023-09-06 2:51 ` Danny Freeman
2023-09-06 12:47 ` Dmitry Gutov
2023-09-07 3:18 ` Danny Freeman
2023-09-07 12:52 ` Dmitry Gutov
2023-09-08 1:04 ` Yuan Fu
2023-09-08 6:40 ` Eli Zaretskii
2023-09-08 20:52 ` Dmitry Gutov
2023-09-09 6:32 ` Eli Zaretskii
2023-09-09 10:24 ` Dmitry Gutov
2023-09-09 11:38 ` Eli Zaretskii
2023-09-09 17:04 ` Dmitry Gutov
2023-09-09 17:28 ` Eli Zaretskii
2023-09-12 0:36 ` Yuan Fu
2023-09-12 10:17 ` Dmitry Gutov
2023-09-08 21:05 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8A2B8A2E-FC24-401B-ACF8-688F2B157FB6@gmail.com \
--to=casouri@gmail.com \
--cc=danny@dfreeman.email \
--cc=dev@rjt.dev \
--cc=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=jostein@secure.kjonigsen.net \
--cc=pedz@easesoftware.com \
--cc=theo@thornhill.no \
--cc=wkirschbaum@gmail.com \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.