emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is it better to add treesitter modes to core?


From: Dmitry Gutov
Subject: Re: Is it better to add treesitter modes to core?
Date: Mon, 8 Jan 2024 14:46:36 +0200
User-agent: Mozilla Thunderbird

On 08/01/2024 08:15, Philip Kaludercic wrote:

In my ideal world, we should have basic editing support in place in
Emacs for typical tasks, and packages should provide extensions.  Most
users don't particularly enjoy starting work with installing a bunch of
extras.

The way VS Code works and its level of popularity seem to say otherwise.

One notable difference is that VS Code prompts users to install the
necessary packages, while with Emacs one has to figure out what to
install (and how to install it in the case of ada-mode).

We were talking about a feature like that for Emacs too, at some point. Aside from cases like ada-mode, it wouldn't be hard to implement.

And yet the Vim repository doesn't have any tree-sitter integration,
it's all third-party. I don't think we'll see it there anytime soon
(or even in the medium term).

I don't know how to check this, but didn't Neovim have built-in
tree-sitter support?

You're thinking of LSP. nvim-treesitter is a separate plugin, with "experimental" in bold in its description.

Possible grammar versioning problems. But the above should be small
and stable enough, nor should they require many changes over the
years.

I don't think this has to be a problem.  Last year I had suggested that
`treesit-install-language-grammar' should download release GitHub
tarballs, not just clone the repository (which requires Git, and is
prone to upstream breakage).

It's a problem anyway when the ts mode in the Emacs release that the user has installed is out of sync with whatever grammar release would be downloaded by the above method.

These releases can also be sparse and outdated: the last tagged version of tree-sitter-ruby is 0.19 from 3 years ago. There was a version update to 0.20 2 years ago but it's not tagged. And there are useful recent changes as well.

And Ada is niche enough that even the argument of having the popular
languages supported OOtB doesn't work.
I think historical context matters here.  Ada is not exactly in
vogue
these days, but it _is_ supported by GCC, and it has an ISO standard.
It's not some random novelty language for people that feel that
Typescript is not edgy enough, or anything like that.
We also happened to support it in Emacs for ages.

And it's still there in ELPA, available for everybody to install.

Note that I don't mean to belittle Stephen's work, nor have any desire
to throw it away, but the sentiment "it's unmaintained, let's bring it
in the core and see what happens" sounds very wrong to me.

Just to clarify, my question was what people would think of adding
ada-mode back to the core, if it were simplified using tree sitter.

ada-ts-mode might look very different from the current ada-mode.

It's unclear which approach the next maintainer of ada-mode is going to take. One of Stephen's outlined alternatives (2) describes reimplementing its own parser on top of tree-sitter (and I'm guessing that he would prefer 2 over 3). That sounds like more work than implementing ada-ts-mode on top of treesit.el like the others.

Oh, and speaking of motivated developers. Someone who knows at least a little Ada should check this out: https://github.com/brownts/ada-ts-mode





reply via email to

[Prev in Thread] Current Thread [Next in Thread]