From: Yuan Fu <casouri@gmail.com>
To: Hugo Thunnissen <devel@hugot.nl>
Cc: "Ihor Radchenko" <yantar92@posteo.net>,
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: Sat, 2 Sep 2023 15:12:32 -0700 [thread overview]
Message-ID: <F90DB8FD-236B-4A33-8407-1950F6ECAB3D@gmail.com> (raw)
In-Reply-To: <87h6oddkm1.fsf@hugot.nl>
> On Sep 2, 2023, at 1:50 AM, Hugo Thunnissen <devel@hugot.nl> wrote:
>
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> Yuan Fu <casouri@gmail.com> writes:
>>
>>> In the months after wrapping up tree-sitter stuff in emacs-29, I was
>>> thinking about how to implement structural navigation and extracting
>>> information from the parser with tree-sitter. In emacs-29 we have
>>> things like treesit-beginning/end-of-defun, and treesit-defun-name. I
>>> was thinking maybe we can generalize this to support getting arbitrary
>>> “thing” at point, move around them, and getting information like the
>>> name of a defun, its arglist, parent of a class, type of an variable
>>> declaration, etc, in a language-agnostic way.
>>
>> Note that Org mode also does all of these using
>> https://orgmode.org/worg/dev/org-element-api.html
>>
>> It would be nice if we could converge to more consistent interface
>> across all the modes. For example, by extending `thing-at-point' to handle
>> parsed elements, not just simplistic regexp-based "thing" boundaries
>> exposed by `thing-at-point' now.
>>
>> Org approaches getting name/begin/end/arguments using a common API:
>>
>> (org-element-property :begin NODE)
>> (org-element-property :end NODE)
>> (org-element-property :contents-begin NODE)
>> (org-element-property :contents-end NODE)
>> (org-element-property :name NODE)
>> (org-element-property :args NODE)
>>
>> Language-agnostic "thing"s will certainly be welcome, especially given
>> that tree-sitter grammars use inconsistent naming schemes, which have to
>> be learned separately, and may even change with grammar versions.
>>
>> I think that both NODE types and attributes can be standardized.
>>
>
> It would be great to see standardization that can work with more than
> just tree-sitter. Depending on how extensive such a generic NODE type
> and accompanying API are, I could see standardization of a lot of things
> that are currently implemented in major modes, to name a few:
>
> - indentation
> - fontification
> - thing-at-point
> - imenu
> - simple forms of completion (variables, function names in buffer)
>
> I have some idea of the underpinnings, but I have never implemented a
> full major mode so it is hard for me to judge the practicality of
> this. How much would be practical to standardize, without needlessly
> complicated/resource-heavy abstractions?
I don’t know which level of standardization you are thinking about, but aren’t they already standardized?
- indentation: indent-line/region-function
- fontification: font-lock-defaults
- thing-at-point: thing-at-point function
- imenu: imenu-create-index-function
- completion: completion-at-point-function
Yuan
next prev parent reply other threads:[~2023-09-02 22:12 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 [this message]
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
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=F90DB8FD-236B-4A33-8407-1950F6ECAB3D@gmail.com \
--to=casouri@gmail.com \
--cc=danny@dfreeman.email \
--cc=dev@rjt.dev \
--cc=devel@hugot.nl \
--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.