Detecting tree-sitter based major-modes for end-user customization and third party functions/packages

Detecting tree-sitter based major-modes for end-user customization and third party functions/packages

[Jostein Kjønigsen]

[-- 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 --]

Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages

[Eli Zaretskii]

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

Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages

[Stefan Monnier]

> 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

Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages

[Jostein Kjønigsen]

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

Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages

[Stefan Monnier]

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

Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages

[Jostein Kjønigsen]

[-- 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 --]

Re: Detecting tree-sitter based major-modes for end-user customization and third party functions/packages

[Stefan Monnier]

> 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