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

[Dmitry Gutov]

On 07/01/2024 19:46, Stefan Kangas wrote:
> Dmitry <dmitry@gutov.dev> writes:
>
> > On Sun, Jan 7, 2024, at 2:34 PM, Philip Kaludercic wrote:
> > > What I am wondering, is if this simplification were to take place, if it
> > > would be possible to add ada-mode (or ada-ts-mode in that case) back to
> > > the core?
> > What is this fetish of adding everything to the core?
> > ELPA is just one 'M-x package-install' away.
>
> In Emacs, whatever real work you need to do, it's often the case that
> "it's just one M-x package-install" away.

That's right. It doesn't work for every purpose, though. Not for 
infrastructure packages (which we expect to be used by other packages), 
nor for features that we want to have enabled by default.

> I see little reason for that.

You don't want ELPA to be used?

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

> Take a look at how much better things are elsewhere and weep:
>
>      https://github.com/vim/vim/tree/master/runtime/syntax
>
> Yes, vim is different, their job is easier and so on and so forth.

It is only better if the features provided in there are reasonably 
complete and well-maintained.

Also note that in no cases Vim bundles advanced completion functionality 
of the kind that Ada-mode has. It's much bigger than any of the files in 
the above dir.

> But
> also consider that treesitter modes are looking far easier to maintain
> than some of the behemoths we have sometimes had to write in ELisp.

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

> We might not want _all_ language support in Emacs, but for the main
> languages: why would we _not_ want it?  While I appreciate the
> importance of workflow related arguments, from the end users point of
> view, it really is a no-brainer which way is better.

I don't really mind having the major modes for most popular languages in 
here, because in those cases the problem of extra traffic is offset by 
the advantage that one can see a problem and contribute a fix that will 
go out to help a lot of people. Even if I don't use a language in 
question myself. But doing that with languages that are unfamiliar to 
most contributors, and have small audience, is questionable.

> This doesn't only apply to prog-modes, but also many text-modes.  Take a
> look at toml-ts-mode.el for example, and tell me one reason why it
> shouldn't be in Emacs core.  Markdown.  YAML.  Stuff like that.

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

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

It would be a good idea for the interested parties to pay more attention 
to ELPA and improve it there. And if we really want basic support for 
Ada in the core, one could extract the "traditional" major mode from it. 
Or perhaps start anew and implement the tree-sitter based mode. Since 
there is an existing (LSP) language server, Eglot could be used for the 
IDE features. And then it would be easier to compare the feature sets.