* Tree sitter: Should *-ts-modes derive from a common base?
@ 2023-03-21 9:30 Phil Sainty
2023-03-22 7:32 ` Dmitry Gutov
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Phil Sainty @ 2023-03-21 9:30 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Tree sitter: Should *-ts-modes derive from a common base?
2023-03-21 9:30 Tree sitter: Should *-ts-modes derive from a common base? Phil Sainty
@ 2023-03-22 7:32 ` Dmitry Gutov
2023-03-25 9:16 ` João Távora
2023-03-22 10:07 ` Daniel Martín
2023-03-23 8:50 ` Phil Sainty
2 siblings, 1 reply; 5+ messages in thread
From: Dmitry Gutov @ 2023-03-22 7:32 UTC (permalink / raw)
To: Phil Sainty, emacs-devel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Tree sitter: Should *-ts-modes derive from a common base?
2023-03-21 9:30 Tree sitter: Should *-ts-modes derive from a common base? Phil Sainty
2023-03-22 7:32 ` Dmitry Gutov
@ 2023-03-22 10:07 ` Daniel Martín
2023-03-23 8:50 ` Phil Sainty
2 siblings, 0 replies; 5+ messages in thread
From: Daniel Martín @ 2023-03-22 10:07 UTC (permalink / raw)
To: Phil Sainty; +Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Tree sitter: Should *-ts-modes derive from a common base?
2023-03-21 9:30 Tree sitter: Should *-ts-modes derive from a common base? Phil Sainty
2023-03-22 7:32 ` Dmitry Gutov
2023-03-22 10:07 ` Daniel Martín
@ 2023-03-23 8:50 ` Phil Sainty
2 siblings, 0 replies; 5+ messages in thread
From: Phil Sainty @ 2023-03-23 8:50 UTC (permalink / raw)
To: emacs-devel; +Cc: dgutov, mardani29
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Tree sitter: Should *-ts-modes derive from a common base?
2023-03-22 7:32 ` Dmitry Gutov
@ 2023-03-25 9:16 ` João Távora
0 siblings, 0 replies; 5+ messages in thread
From: João Távora @ 2023-03-25 9:16 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Phil Sainty, emacs-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-03-25 9:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-21 9:30 Tree sitter: Should *-ts-modes derive from a common base? Phil Sainty
2023-03-22 7:32 ` Dmitry Gutov
2023-03-25 9:16 ` João Távora
2023-03-22 10:07 ` Daniel Martín
2023-03-23 8:50 ` Phil Sainty
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).