unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Detecting tree-sitter based major-modes for end-user customization and third party functions/packages
@ 2022-12-20 11:35 Jostein Kjønigsen
  2022-12-20 14:21 ` Eli Zaretskii
  2022-12-20 15:38 ` Stefan Monnier
  0 siblings, 2 replies; 7+ messages in thread
From: Jostein Kjønigsen @ 2022-12-20 11:35 UTC (permalink / raw)
  To: Ergus via Emacs development discussions., Yuan Fu

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]

Hey everyone.

This may or may not have been answered in an earlier thread about the 
subject, but I couldn't really find it, so if this email and question 
represents a duplicate: sorry in advance.

With that said, I'll get straight down to business.

While as a major-mode author, I can decide to use tree-sitter to 
implement key functionality, we don't expect end-users to (need to) have 
the same level awareness about the technology used to implement the 
modes they are consuming.

However end-users often want to customize Emacs based on major-mode 
agnostic properties of the current major-mode none the less. Examples 
are adding hooks for prog-mode, c-mode-common-mode (from cc-mode), etc. 
This may also apply to other third-party packages, in how they interact 
with buffers (if prog-mode do this, if text-mode do that, etc).

I expect these kinda of needs to arise for tree-sitter based major-modes 
sooner rather than later, where one may be able to leverage tree-sitter 
node-manipulation functions rather than use text-based equivalents.

But to be able to leverage tree-sitter based functions, one would first 
need to know that one is interacting with a tree-sitter based 
major-mode. And to customize one, one would need a hook.

So how do we plan to expose this to end-users and other developers?

Looking at (treesit-major-mode-setup), I can't see it leaving any traces 
to be reliably detected later. Should we add some (documented) 
buffer-local variables to be able to detect this later? Should we create 
a mostly empty minor-mode for easy detection and ability to add hooks?

Or does anyone have any other suggestions for how we can solve this 
user-facing need of tree-sitter?

--
Kind regards
*Jostein Kjønigsen*
jostein.kjønigsen.no <https://jostein.kjønigsen.no>
jostein@kjonigsen.net - jostein@gmail.com

[-- Attachment #2: Type: text/html, Size: 2523 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages
  2022-12-20 11:35 Detecting tree-sitter based major-modes for end-user customization and third party functions/packages Jostein Kjønigsen
@ 2022-12-20 14:21 ` Eli Zaretskii
  2022-12-20 15:38 ` Stefan Monnier
  1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2022-12-20 14:21 UTC (permalink / raw)
  To: Jostein Kjønigsen; +Cc: emacs-devel, casouri

> Date: Tue, 20 Dec 2022 12:35:57 +0100
> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
> 
> While as a major-mode author, I can decide to use tree-sitter to implement key functionality, we don't expect
> end-users to (need to) have the same level awareness about the technology used to implement the modes
> they are consuming.
> 
> However end-users often want to customize Emacs based on major-mode agnostic properties of the current
> major-mode none the less. Examples are adding hooks for prog-mode, c-mode-common-mode (from
> cc-mode), etc. This may also apply to other third-party packages, in how they interact with buffers (if
> prog-mode do this, if text-mode do that, etc).
> 
> I expect these kinda of needs to arise for tree-sitter based major-modes sooner rather than later, where one
> may be able to leverage tree-sitter node-manipulation functions rather than use text-based equivalents.
> 
> But to be able to leverage tree-sitter based functions, one would first need to know that one is interacting with
> a tree-sitter based major-mode. And to customize one, one would need a hook.
> 
> So how do we plan to expose this to end-users and other developers?

We already have a discussion about this, here:

  https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00822.html

So just chime in there.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages
  2022-12-20 11:35 Detecting tree-sitter based major-modes for end-user customization and third party functions/packages Jostein Kjønigsen
  2022-12-20 14:21 ` Eli Zaretskii
@ 2022-12-20 15:38 ` Stefan Monnier
  2022-12-20 19:44   ` Jostein Kjønigsen
  1 sibling, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2022-12-20 15:38 UTC (permalink / raw)
  To: Jostein Kjønigsen; +Cc: Ergus via Emacs development discussions., Yuan Fu

> Looking at (treesit-major-mode-setup), I can't see it leaving any traces to
> be reliably detected later. Should we add some (documented) buffer-local
> variables to be able to detect this later? Should we create a mostly empty
> minor-mode for easy detection and ability to add hooks?

(treesit-parser-list) seems like a good first approximation, tho I guess
it depends exactly what they want to do with that info.


        Stefan




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages
  2022-12-20 15:38 ` Stefan Monnier
@ 2022-12-20 19:44   ` Jostein Kjønigsen
  2022-12-20 20:03     ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: Jostein Kjønigsen @ 2022-12-20 19:44 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: Ergus via Emacs development discussions., Yuan Fu,
	Theodor Thornhill

On 20.12.2022 16:38, Stefan Monnier wrote:
>> Looking at (treesit-major-mode-setup), I can't see it leaving any traces to
>> be reliably detected later. Should we add some (documented) buffer-local
>> variables to be able to detect this later? Should we create a mostly empty
>> minor-mode for easy detection and ability to add hooks?
> (treesit-parser-list) seems like a good first approximation, tho I guess
> it depends exactly what they want to do with that info.
>
>
>          Stefan
>
That name isn't very intuitive for what it does, but it seems to work. I 
therefore kinda of second Theo's suggestion in the other thread 
mentioned by Eli about possibly trying to come up with a nicer/more 
obvious syntax for it.

Either way, thanks for a quick and accurate answer!

--
Jostein




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages
  2022-12-20 19:44   ` Jostein Kjønigsen
@ 2022-12-20 20:03     ` Stefan Monnier
  2022-12-20 20:14       ` Jostein Kjønigsen
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2022-12-20 20:03 UTC (permalink / raw)
  To: Jostein Kjønigsen
  Cc: jostein, Ergus via Emacs development discussions., Yuan Fu,
	Theodor Thornhill

>>> Looking at (treesit-major-mode-setup), I can't see it leaving any traces to
>>> be reliably detected later. Should we add some (documented) buffer-local
>>> variables to be able to detect this later? Should we create a mostly empty
>>> minor-mode for easy detection and ability to add hooks?
>> (treesit-parser-list) seems like a good first approximation, tho I guess
>> it depends exactly what they want to do with that info.
> That name isn't very intuitive for what it does,

AFAIK what it does is return a list of parsers currently setup in the
buffer, so its name seems very intuitive.

Maybe you're thinking of using it for some other purpose?
If so, please describe which one.


        Stefan




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages
  2022-12-20 20:03     ` Stefan Monnier
@ 2022-12-20 20:14       ` Jostein Kjønigsen
  2022-12-20 20:21         ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: Jostein Kjønigsen @ 2022-12-20 20:14 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: jostein, Ergus via Emacs development discussions., Yuan Fu,
	Theodor Thornhill

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

On 20.12.2022 21:03, Stefan Monnier wrote:
>>> (treesit-parser-list) seems like a good first approximation, tho I guess
>>> it depends exactly what they want to do with that info.
>> That name isn't very intuitive for what it does,
> AFAIK what it does is return a list of parsers currently setup in the
> buffer, so its name seems very intuitive.
>
> Maybe you're thinking of using it for some other purpose?
> If so, please describe which one.
>
>
>          Stefan
>
At this point treesitter is new, and I'm interested in investigating its 
general capabilities outside of specific major-modes.

Take for instance the ability to paredit-like navigate up the current 
parse-tree, regardless of major-mode, as long as it uses tree-sitter.

Something like the code below:

(defun my-auto-parent ()
   (interactive)
   (when (treesit-parser-list)
     (goto-char (treesit-node-start (treesit-node-parent 
(treesit-node-at (point)))))))

Basically I just want a true or false check for if I'll be able to move 
on to using treesit-* functionality, or possibly using that specifically 
in my hooks to replace "primitive" functions and bindings with 
tree-aware functions instead.

Like I said, (treesit-parser-list) does indeed work, but in a case like 
this where you don't really care about /what/ parser is being used, only 
that -a- parser is being used, a simpler, more appropriately named 
function might be beneficial.

Just my 2 cents.

--
Jostein

[-- Attachment #2: Type: text/html, Size: 2160 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages
  2022-12-20 20:14       ` Jostein Kjønigsen
@ 2022-12-20 20:21         ` Stefan Monnier
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2022-12-20 20:21 UTC (permalink / raw)
  To: Jostein Kjønigsen
  Cc: jostein, Ergus via Emacs development discussions., Yuan Fu,
	Theodor Thornhill

> Something like the code below:
>
> (defun my-auto-parent ()
>   (interactive)
>   (when (treesit-parser-list)
>     (goto-char (treesit-node-start (treesit-node-parent (treesit-node-at
> (point)))))))

Even if Tree-sitter is available and there's a parser active in the
current buffer, `treesit-node-at` may return nil, so the better code is
probably something like

    (defun my-auto-parent ()
      (interactive)
      (let ((node (treesit-node-at (point))))
        (if node
            (goto-char (treesit-node-start (treesit-node-parent node)))
          <do something else>)))

and then lobby for `treesit-node-at` to return nil rather
than signal an error when there's no parser, tho an alternative is

    (defun my-auto-parent ()
      (interactive)
      (condition-case nil
          (let ((node (treesit-node-at (point))))
            (if node
                (goto-char (treesit-node-start (treesit-node-parent node)))
              <do something else>))
        (treesit-error
         <do yet something else, or maybe not>)))



        Stefan




^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-12-20 20:21 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-12-20 11:35 Detecting tree-sitter based major-modes for end-user customization and third party functions/packages Jostein Kjønigsen
2022-12-20 14:21 ` Eli Zaretskii
2022-12-20 15:38 ` Stefan Monnier
2022-12-20 19:44   ` Jostein Kjønigsen
2022-12-20 20:03     ` Stefan Monnier
2022-12-20 20:14       ` Jostein Kjønigsen
2022-12-20 20:21         ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).