all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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


  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.