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: Stefan Kangas
Subject: Re: Is it better to add treesitter modes to core?
Date: Mon, 8 Jan 2024 21:20:04 -0800

Dmitry Gutov <dmitry@gutov.dev> writes:

>> I see little reason for that.
>
> You don't want ELPA to be used?

I do, of course.  :-)

No one has proposed to add everything to core.

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

Yes, but VSCode has some niceties that we don't.  When Emacs displays an
unobtrusive little popup in the right corner saying

    "Hello, this looks like $LANGUAGE, do you want to install support
    for that?  [YES/NO]"

then I will agree with you that it's less important to keep stuff in
core.

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

Do you have any reason to believe that they're not?  For the very small
sample set that I've looked at, they certainly blew the corresponding
Emacs modes out of the water.

For some of the things listed there, we don't even have a mode.

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

Yes, fully agreed.

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

I'm not yet convinced that we should add a new ada-ts-mode.el to core.
The fact that it wouldn't have a dedicated maintainer deeply invested in
the language certainly speaks against it.

I'm also not sure that we would want something half-baked in core for a
language with a small user base, since that makes it less likely that an
Emacs mode maintainer will step forward.

The strongest argument for keeping the more venerable languages around
is that their support is super stable, after all.



reply via email to

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