Tree sitter: Should *-ts-modes derive from a common base?

Tree sitter: Should *-ts-modes derive from a common base?

[Phil Sainty]

WRT 
https://emacs.stackexchange.com/questions/76400/how-do-i-check-if-the-current-buffer-has-a-treesit-parser

I wondered whether derived-mode-p could conveniently establish
some kind of base ts-mode, but that doesn't appear to be the case
(or at least not for the examples I looked at).

I was pondering something like this:

(define-derived-mode prog-ts-mode prog-mode "Prog(TS)"
   "Major mode for editing source code with tree-sitter support.")

And then all the *-ts-mode derivatives of prog-mode changed like so:

- (define-derived-mode cmake-ts-mode prog-mode "CMake"
+ (define-derived-mode cmake-ts-mode prog-ts-mode "CMake"

The case I've spotted thus far which wouldn't work is the CSS modes,
where we have this:

(define-derived-mode css-base-mode prog-mode "CSS"
(define-derived-mode css-mode css-base-mode "CSS"
(define-derived-mode css-ts-mode css-base-mode "CSS"

That could be refactored if this idea was a sensible one.

Apologies if this has been discussed before... it seems like
something which might have come up, but I couldn't find anything
relevant.  I'm not across the tree-sitter work in general though,
and maybe this is a bad idea for some reason.


-Phil

Re: Tree sitter: Should *-ts-modes derive from a common base?

[Dmitry Gutov]

On 21/03/2023 11:30, Phil Sainty wrote:
> The case I've spotted thus far which wouldn't work is the CSS modes,
> where we have this:
> 
> (define-derived-mode css-base-mode prog-mode "CSS"
> (define-derived-mode css-mode css-base-mode "CSS"
> (define-derived-mode css-ts-mode css-base-mode "CSS"
> 
> That could be refactored if this idea was a sensible one.

How would you refactor it? We don't have multiple inheritance.

> Apologies if this has been discussed before... it seems like
> something which might have come up, but I couldn't find anything
> relevant.  I'm not across the tree-sitter work in general though,
> and maybe this is a bad idea for some reason.

There's been a bunch of discussions on the bug tracker, and at least one 
where the participants landed on the xxx-base-mode design. I don't have 
the bug number at hand, though.

Re: Tree sitter: Should *-ts-modes derive from a common base?

[João Távora]

On Wed, Mar 22, 2023 at 7:32 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 21/03/2023 11:30, Phil Sainty wrote:
> > The case I've spotted thus far which wouldn't work is the CSS modes,
> > where we have this:
> >
> > (define-derived-mode css-base-mode prog-mode "CSS"
> > (define-derived-mode css-mode css-base-mode "CSS"
> > (define-derived-mode css-ts-mode css-base-mode "CSS"
> >
> > That could be refactored if this idea was a sensible one.
>
> How would you refactor it? We don't have multiple inheritance.

There are many mechanisms of code reuse besides inheritance.
In lisp-based modes there is the the lisp-mode-variables, for
example.  So IMO it's fine to use a combination of single
inheritance and such a mechanism.

Phil's idea is very pertinent and should be addressed sooner
not later, because the potential for messy duplicated code or
just misinheritance is high later down the road.  The lisp-mode
fiasco comes to mind.

João

Re: Tree sitter: Should *-ts-modes derive from a common base?

[Daniel Martín]

Phil Sainty <psainty@orcon.net.nz> writes:

> WRT
> https://emacs.stackexchange.com/questions/76400/how-do-i-check-if-the-current-buffer-has-a-treesit-parser
>
> I wondered whether derived-mode-p could conveniently establish
> some kind of base ts-mode, but that doesn't appear to be the case
> (or at least not for the examples I looked at).
>
> I was pondering something like this:
>
> (define-derived-mode prog-ts-mode prog-mode "Prog(TS)"
>   "Major mode for editing source code with tree-sitter support.")
>
> And then all the *-ts-mode derivatives of prog-mode changed like so:
>
> - (define-derived-mode cmake-ts-mode prog-mode "CMake"
> + (define-derived-mode cmake-ts-mode prog-ts-mode "CMake"
>
> The case I've spotted thus far which wouldn't work is the CSS modes,
> where we have this:
>
> (define-derived-mode css-base-mode prog-mode "CSS"
> (define-derived-mode css-mode css-base-mode "CSS"
> (define-derived-mode css-ts-mode css-base-mode "CSS"
>

Adding a common Tree-sitter base mode might be useful for some use cases
we'd need to describe in more detail, but I don't think it's the best
solution for the problem of checking if a Tree-sitter parser is
available or not.  For example, some major modes offer Tree-sitter
functionality without introducing a specific new Tree-sitter-based major
mode, so having a common inheritance wouldn't help here, I think.

Aren't (treesit-parser-list BUFFER) and (treesit-parser-language PARSER)
the best ways to check if Tree-sitter can be used in a particular
buffer, for a particular language?

Re: Tree sitter: Should *-ts-modes derive from a common base?

[Phil Sainty]

Dmitry Gutov wrote:
> > (define-derived-mode css-base-mode prog-mode "CSS"
> > (define-derived-mode css-mode css-base-mode "CSS"
> > (define-derived-mode css-ts-mode css-base-mode "CSS"
> >
> > That could be refactored if this idea was a sensible one.
> 
> How would you refactor it? We don't have multiple inheritance.

My thought was simply to remove css-base-mode (which looks to have
been added solely for the new css-mode/css-ts-mode split and is only
being used for its body) and instead simply have css-ts-mode and
css-mode both directly call a common function in their own body.


> There's been a bunch of discussions on the bug tracker, and at
> least one where the participants landed on the xxx-base-mode
> design.  I don't have the bug number at hand, though.

Right, I figured it would have come up.  I'll happily defer to
conclusions made by people who've thought about this more.



Daniel Martín wrote:
> some major modes offer Tree-sitter functionality without introducing
> a specific new Tree-sitter-based major mode, so having a common
> inheritance wouldn't help here, I think.

Ah, ok.  Yes, agreed.


> Aren't (treesit-parser-list BUFFER) and (treesit-parser-language
> PARSER) the best ways to check if Tree-sitter can be used in a
> particular buffer, for a particular language?

I'll take your word for it.  The stackexchange user I mentioned
initially has done something slightly different:

  (defun treesit-enabled-p ()
    "Checks if the current buffer has a treesit parser."
    (and (fboundp 'treesit-available-p)
         (treesit-available-p)
         (treesit-language-at (point))))

( https://emacs.stackexchange.com/questions/76400 )

However using treesit-language-at or treesit-parser-language
doesn't seem much less cumbersome -- they're not defined in my
build of Emacs 29 (without tree-sitter support), so the fboundp
is still needed at minimum.  If that's the best we have right
now, perhaps a standard predicate should be added for this.


-Phil