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

[Philip Kaludercic <philipk@posteo.net>]

Dmitry Gutov <dmitry@gutov.dev> writes:

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

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

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

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

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

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

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

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