Turning c-ts-mode.el, go-ts-mode.el, csharp-ts-mode.el etc into :core packages?

Turning c-ts-mode.el, go-ts-mode.el, csharp-ts-mode.el etc into :core packages?

[Yuan Fu]

What are the implications of turning something into a :core package? I can’t find much description of it. If my understanding of it is correct, I think it would be beneficial to make new tree-sitter modes into :core packages. Right now they are pretty bare-bones, and haven’t been “battle-tested”. Making them core packages would allow us gradually improve them and fix errors that come up. Those files I mentioned in the subject are new files, if that matters. But I don’t know if there are any downsides of turning something into a :core package.

The new tree-sitter related files we have are:
- c-ts-mode.el
- java-ts-mode.el
- rust-ts-mode.el
- go-ts-mode.el
- dockerfile-ts-mode.el
- cmake-ts-mode.el
- yaml-ts-mode.el
- typescript-ts-mode.el
- ruby-ts-mode.el
- toml-ts-mode.el

And we have a few “combined” files:
- python.el (already a :core package)
- js.el
- sh-script.el

Yuan

Re: Turning c-ts-mode.el, go-ts-mode.el, csharp-ts-mode.el etc into :core packages?

[Holger Schurig]

On Mar, 2023-03-05 14:17, Yuan Fu wrote ...
> - c-ts-mode.el

I understand what :core actually means.

But I think we don't need to battle test c-ts-mode.el. We already know
that it leaves to be desired --- in cases where C or C++ macros are
used.

For my programs, I got worse font-locking and indentation than with the
the non-TS modes.

Re: Turning c-ts-mode.el, go-ts-mode.el, csharp-ts-mode.el etc into :core packages?

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sun, 5 Mar 2023 14:41:17 -0800
> 
> What are the implications of turning something into a :core package? I can’t find much description of it. If my understanding of it is correct, I think it would be beneficial to make new tree-sitter modes into :core packages. Right now they are pretty bare-bones, and haven’t been “battle-tested”. Making them core packages would allow us gradually improve them and fix errors that come up. Those files I mentioned in the subject are new files, if that matters. But I don’t know if there are any downsides of turning something into a :core package.
> 
> The new tree-sitter related files we have are:
> - c-ts-mode.el
> - java-ts-mode.el
> - rust-ts-mode.el
> - go-ts-mode.el
> - dockerfile-ts-mode.el
> - cmake-ts-mode.el
> - yaml-ts-mode.el
> - typescript-ts-mode.el
> - ruby-ts-mode.el
> - toml-ts-mode.el
> 
> And we have a few “combined” files:
> - python.el (already a :core package)
> - js.el
> - sh-script.el

Isn't :core only relevant for ELPA packages and not for something that
is bundled with Emacs?

Re: Turning c-ts-mode.el, go-ts-mode.el, csharp-ts-mode.el etc into :core packages?

[Eli Zaretskii]

> From: Holger Schurig <holgerschurig@gmail.com>
> Date: Tue, 7 Mar 2023 03:18:55 -0800
> 
> On Mar, 2023-03-05 14:17, Yuan Fu wrote ...
> > - c-ts-mode.el
> 
> I understand what :core actually means.
> 
> But I think we don't need to battle test c-ts-mode.el. We already know
> that it leaves to be desired --- in cases where C or C++ macros are
> used.
> 
> For my programs, I got worse font-locking and indentation than with the
> the non-TS modes.

That is one important reason why these packages are completely
optional: if you don't like the results, simply don't use them until
they become better.

Re: Turning c-ts-mode.el, go-ts-mode.el, csharp-ts-mode.el etc into :core packages?

[Dmitry Gutov]

On 06/03/2023 00:41, Yuan Fu wrote:
> What are the implications of turning something into a :core package? I can’t find much description of it. If my understanding of it is correct, I think it would be beneficial to make new tree-sitter modes into :core packages. Right now they are pretty bare-bones, and haven’t been “battle-tested”. Making them core packages would allow us gradually improve them and fix errors that come up. Those files I mentioned in the subject are new files, if that matters. But I don’t know if there are any downsides of turning something into a :core package.

Most of the associated overhead is having to keep in mind the version of 
Emacs that each packages advertises compatibility with. Which makes 
using new features (or fixes) from future Emacs versions harder 
(requiring versions checks, etc).

We could also make treesit.el into a :core package at some point, if any 
of the packages will need some new changes. Although this one will 
likely depend on changes in treesit.c even more often. But for this 
package, at least, it might be worth it to set the "Version:" header in 
advance.

Re: Turning c-ts-mode.el, go-ts-mode.el, csharp-ts-mode.el etc into :core packages?

[Yuan Fu]

> On Mar 7, 2023, at 5:19 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sun, 5 Mar 2023 14:41:17 -0800
>> 
>> What are the implications of turning something into a :core package? I can’t find much description of it. If my understanding of it is correct, I think it would be beneficial to make new tree-sitter modes into :core packages. Right now they are pretty bare-bones, and haven’t been “battle-tested”. Making them core packages would allow us gradually improve them and fix errors that come up. Those files I mentioned in the subject are new files, if that matters. But I don’t know if there are any downsides of turning something into a :core package.
>> 
>> The new tree-sitter related files we have are:
>> - c-ts-mode.el
>> - java-ts-mode.el
>> - rust-ts-mode.el
>> - go-ts-mode.el
>> - dockerfile-ts-mode.el
>> - cmake-ts-mode.el
>> - yaml-ts-mode.el
>> - typescript-ts-mode.el
>> - ruby-ts-mode.el
>> - toml-ts-mode.el
>> 
>> And we have a few “combined” files:
>> - python.el (already a :core package)
>> - js.el
>> - sh-script.el
> 
> Isn't :core only relevant for ELPA packages and not for something that
> is bundled with Emacs?

I think bundled packages can become :core packages too, like eldoc.el did.

Yuan

Re: Turning c-ts-mode.el, go-ts-mode.el, csharp-ts-mode.el etc into :core packages?

[Yuan Fu]

> On Mar 7, 2023, at 7:06 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 06/03/2023 00:41, Yuan Fu wrote:
>> What are the implications of turning something into a :core package? I can’t find much description of it. If my understanding of it is correct, I think it would be beneficial to make new tree-sitter modes into :core packages. Right now they are pretty bare-bones, and haven’t been “battle-tested”. Making them core packages would allow us gradually improve them and fix errors that come up. Those files I mentioned in the subject are new files, if that matters. But I don’t know if there are any downsides of turning something into a :core package.
> 
> Most of the associated overhead is having to keep in mind the version of Emacs that each packages advertises compatibility with. Which makes using new features (or fixes) from future Emacs versions harder (requiring versions checks, etc).

I wish package.el has something like “install last version of xxx package compatible with Emacs yyy”. Then we can just bump the minimum required Emacs version when a new Emacs release come out, and use new features. Anyway, checking versions to use new Emacs feature is IMO an acceptable price to pay.

> 
> We could also make treesit.el into a :core package at some point, if any of the packages will need some new changes. Although this one will likely depend on changes in treesit.c even more often. But for this package, at least, it might be worth it to set the "Version:" header in advance.

Maybe, thought I don’t think we’ll need to anytime soon.

Yuan

Re: Turning c-ts-mode.el, go-ts-mode.el, csharp-ts-mode.el etc into :core packages?

[Dmitry Gutov]

On 08/03/2023 06:19, Yuan Fu wrote:
> 
> 
>> On Mar 7, 2023, at 7:06 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:
>>
>> On 06/03/2023 00:41, Yuan Fu wrote:
>>> What are the implications of turning something into a :core package? I can’t find much description of it. If my understanding of it is correct, I think it would be beneficial to make new tree-sitter modes into :core packages. Right now they are pretty bare-bones, and haven’t been “battle-tested”. Making them core packages would allow us gradually improve them and fix errors that come up. Those files I mentioned in the subject are new files, if that matters. But I don’t know if there are any downsides of turning something into a :core package.
>>
>> Most of the associated overhead is having to keep in mind the version of Emacs that each packages advertises compatibility with. Which makes using new features (or fixes) from future Emacs versions harder (requiring versions checks, etc).
> 
> I wish package.el has something like “install last version of xxx package compatible with Emacs yyy”. Then we can just bump the minimum required Emacs version when a new Emacs release come out, and use new features. Anyway, checking versions to use new Emacs feature is IMO an acceptable price to pay.

Yes, unfortunately, ELPA repositories only keep one latest version.