Ada-mode to be abandoned?

Ada-mode to be abandoned?

[Philip Kaludercic]

I recently came across this message on the ada-mode-users' mailing list:

  https://lists.nongnu.org/archive/html/ada-mode-users/2023-11/msg00000.html

Stephen (the maintainer, in the CC's) indicates that he would like to
retire from maintenance, which might mean that the package could become
abandon-ware.

One note he makes is that the current implementation could be
simplified, by just using tree-sitter, instead of the approach that
makes use of a custom parser:

--8<---------------cut here---------------start------------->8---
2) Drop the wisitoken parser generator and runtime, use tree-sitter
   instead. This requires writing a wrapper for tree-sitter to match
   the wisitoken syntax-tree API; then the current wisi indentation
   code can be used.

   This maintains all of the ada-mode features, while reducing the
   maintenance burden significantly.

   I believe the tree-sitter error correction is less powerful than
   wisitoken, but it would be interesting to see if that matters in
   practice.
--8<---------------cut here---------------end--------------->8---

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?  I would be glad to help out, since I've been interested in
working with Ada for a while but never got it to work, I have just been
struggling with understanding how `treesit-font-lock-rules' is supposed
to be used, so some help would be appreciated.

-- 
Philip Kaludercic

Re: Ada-mode to be abandoned?

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Sun, 07 Jan 2024 12:34:31 +0000
> 
> 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?

It would be fine by me, but we also need to hear from whoever steps
forward to keep maintaining that mode.

Re: Ada-mode to be abandoned?

[Dmitry]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

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.

And Ada is niche enough that even the argument of having the popular languages supported OOtB doesn't work.

[-- Attachment #2: Type: text/html, Size: 719 bytes --]

Re: Ada-mode to be abandoned?

[Eli Zaretskii]

> Date: Sun, 07 Jan 2024 17:21:49 +0200
> From: Dmitry <dmitry@gutov.dev>
> Cc: "Stephen Leake" <stephen_leake@stephe-leake.org>
> 
> What is this fetish of adding everything to the core?
> ELPA is just one 'M-x package-install' away.
> 
> And Ada is niche enough that even the argument of having the popular languages supported OOtB
> doesn't work.

OTOH, adding it to core shouldn't interfere with anything.  Also,
AFAIR, the fact that ada-mode was moved out of core was deemed a
mistake at the time, no?

(Anyway, calling other people's requests "fetish" is unkind at best.)

Re: Ada-mode to be abandoned?

[Dmitry]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

On Sun, Jan 7, 2024, at 5:25 PM, Eli Zaretskii wrote:
> OTOH, adding it to core shouldn't interfere with anything.
It's an extra burden to contributors: due to the limitations of our development workflow, everybody has to be subscribed to everything.

Perhaps it doesn't make a difference to you, but I routinely have to page through notifications for commits and bug reports to features that I have no interest in (nor ability to meaningfully contribute). Such as ERC, for example.

Or recall the recent troubles with Org, which wasted a lot of everybody's time.
> Also,
> AFAIR, the fact that ada-mode was moved out of core was deemed a
> mistake at the time, no?
Deemed a mistake by whom? Not by the author, as I recall.

[-- Attachment #2: Type: text/html, Size: 1107 bytes --]

Re: Ada-mode to be abandoned?

[Eli Zaretskii]

> Date: Sun, 07 Jan 2024 17:54:23 +0200
> From: Dmitry <dmitry@gutov.dev>
> Cc: "Philip Kaludercic" <philipk@posteo.net>, emacs-devel@gnu.org,
>  "Stephen Leake" <stephen_leake@stephe-leake.org>
> 
> On Sun, Jan 7, 2024, at 5:25 PM, Eli Zaretskii wrote:
> 
>  OTOH, adding it to core shouldn't interfere with anything.
> 
> It's an extra burden to contributors: due to the limitations of our development workflow, everybody has
> to be subscribed to everything.

Are there many contributors to ada-mode?

> Perhaps it doesn't make a difference to you, but I routinely have to page through notifications for
> commits and bug reports to features that I have no interest in (nor ability to meaningfully contribute).
> Such as ERC, for example.

Email filtering could help with that, perhaps?

> Or recall the recent troubles with Org, which wasted a lot of everybody's time.

Org's development rate is much higher than ada-mode could ever be.

>  Also,
>  AFAIR, the fact that ada-mode was moved out of core was deemed a
>  mistake at the time, no?
> 
> Deemed a mistake by whom? Not by the author, as I recall.

That's not my recollection.  But I could be mistaken.

Re: Ada-mode to be abandoned?

[Dmitry Gutov]

On 07/01/2024 18:55, Eli Zaretskii wrote:
>> Date: Sun, 07 Jan 2024 17:54:23 +0200
>> From: Dmitry <dmitry@gutov.dev>
>> Cc: "Philip Kaludercic" <philipk@posteo.net>, emacs-devel@gnu.org,
>>   "Stephen Leake" <stephen_leake@stephe-leake.org>
>>
>> On Sun, Jan 7, 2024, at 5:25 PM, Eli Zaretskii wrote:
>>
>>   OTOH, adding it to core shouldn't interfere with anything.
>>
>> It's an extra burden to contributors: due to the limitations of our development workflow, everybody has
>> to be subscribed to everything.
> 
> Are there many contributors to ada-mode?

I'm talking about Emacs contributors.

>> Perhaps it doesn't make a difference to you, but I routinely have to page through notifications for
>> commits and bug reports to features that I have no interest in (nor ability to meaningfully contribute).
>> Such as ERC, for example.
> 
> Email filtering could help with that, perhaps?

Probably not: the commit messages are not always used consistently, and 
if one filters out messages by body contents, it risks false positives, 
e.g. in cases where a commit touches many packages as once.

Re: Ada-mode to be abandoned?

[Eli Zaretskii]

> Date: Mon, 8 Jan 2024 04:14:15 +0200
> Cc: philipk@posteo.net, emacs-devel@gnu.org, stephen_leake@stephe-leake.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 07/01/2024 18:55, Eli Zaretskii wrote:
> >> Date: Sun, 07 Jan 2024 17:54:23 +0200
> >> From: Dmitry <dmitry@gutov.dev>
> >> Cc: "Philip Kaludercic" <philipk@posteo.net>, emacs-devel@gnu.org,
> >>   "Stephen Leake" <stephen_leake@stephe-leake.org>
> >>
> >> On Sun, Jan 7, 2024, at 5:25 PM, Eli Zaretskii wrote:
> >>
> >>   OTOH, adding it to core shouldn't interfere with anything.
> >>
> >> It's an extra burden to contributors: due to the limitations of our development workflow, everybody has
> >> to be subscribed to everything.
> > 
> > Are there many contributors to ada-mode?
> 
> I'm talking about Emacs contributors.
> 
> >> Perhaps it doesn't make a difference to you, but I routinely have to page through notifications for
> >> commits and bug reports to features that I have no interest in (nor ability to meaningfully contribute).
> >> Such as ERC, for example.
> > 
> > Email filtering could help with that, perhaps?
> 
> Probably not: the commit messages are not always used consistently, and 
> if one filters out messages by body contents, it risks false positives, 
> e.g. in cases where a commit touches many packages as once.

OK, but at least IME there's no problem at all to deal with the email
flow due to additions of packages.

Re: Ada-mode to be abandoned?

[Eli Zaretskii]

> Date: Mon, 08 Jan 2024 05:36:46 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: philipk@posteo.net, emacs-devel@gnu.org,
> 	stephen_leake@stephe-leake.org
> 
> > >> Perhaps it doesn't make a difference to you, but I routinely have to page through notifications for
> > >> commits and bug reports to features that I have no interest in (nor ability to meaningfully contribute).
> > >> Such as ERC, for example.
> > > 
> > > Email filtering could help with that, perhaps?
> > 
> > Probably not: the commit messages are not always used consistently, and 
> > if one filters out messages by body contents, it risks false positives, 
> > e.g. in cases where a commit touches many packages as once.
> 
> OK, but at least IME there's no problem at all to deal with the email
> flow due to additions of packages.

And in addition, bug reports about ELPA packages are also sent to
debbugs, so the traffic is basically unaffected by whether a package
is in core or on ELPA.

Re: Ada-mode to be abandoned?

[Dmitry Gutov]

On 08/01/2024 14:22, Eli Zaretskii wrote:
>> Date: Mon, 08 Jan 2024 05:36:46 +0200
>> From: Eli Zaretskii<eliz@gnu.org>
>> Cc:philipk@posteo.net,emacs-devel@gnu.org,
>> 	stephen_leake@stephe-leake.org
>>
>>>>> Perhaps it doesn't make a difference to you, but I routinely have to page through notifications for
>>>>> commits and bug reports to features that I have no interest in (nor ability to meaningfully contribute).
>>>>> Such as ERC, for example.
>>>> Email filtering could help with that, perhaps?
>>> Probably not: the commit messages are not always used consistently, and
>>> if one filters out messages by body contents, it risks false positives,
>>> e.g. in cases where a commit touches many packages as once.
>> OK, but at least IME there's no problem at all to deal with the email
>> flow due to additions of packages.
> And in addition, bug reports about ELPA packages are also sent to
> debbugs, so the traffic is basically unaffected by whether a package
> is in core or on ELPA.

It would indeed be worse if Org didn't have its own bug tracker.

Re: Ada-mode to be abandoned?

[Po Lu]

Dmitry <dmitry@gutov.dev> writes:

> It's an extra burden to contributors: due to the limitations of our
> development workflow, everybody has to be subscribed to everything.
>
> Perhaps it doesn't make a difference to you, but I routinely have to
> page through notifications for commits and bug reports to features
> that I have no interest in (nor ability to meaningfully
> contribute).  Such as ERC, for example.

We also consider packages in ELPA components of Emacs for which we are
responsible, and bug reports for them do appear on our bug tracker from
time to time.  I suggest ignoring bug reports or commits with titles
that you are not concerned with.

The crucial difference between packages and translations is that once
they are complete, they are for good, and developments in other
components only infrequently affect them.  Maintainership is largely a
matter of fixing bugs, which is no obligation of yours.

> Or recall the recent troubles with Org, which wasted a lot of
> everybody's time.

Which, whose, when?

Re: Ada-mode to be abandoned?

[Daniel Mendler via Emacs development discussions.]

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.
>
> And Ada is niche enough that even the argument of having the popular
> languages supported OOtB doesn't work.

I agree with Dmitry here. Also, recently there has also been a
discussion to add a `bicep-ts-mode' to Emacs core, with the argument
being that VSCode supports it. Makes sense, it is a Microsoft product to
help using Microsoft products. The description of Bicep on Github
(https://github.com/Azure/bicep) is "Bicep is a declarative language for
describing and deploying Azure resources". Does Bicep really need to be
part of Emacs core? Couldn't it be added to ELPA instead?

Daniel

Re: Ada-mode to be abandoned?

[Alfred M. Szmidt]

There is a big difference, ADA is a supported language by GCC, our
compiler.  That is plenty of a reason why we would want to make sure
ada-mode just works in GNU Emacs.

Microsoft is not GNU, and are activley hostile toward our cause, so
supporting their languages isn't a priority for the GNU project.

Re: Ada-mode to be abandoned?

[Dmitry]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

On Sun, Jan 7, 2024, at 5:34 PM, Daniel Mendler wrote:
> The description of Bicep on Github
> (https://github.com/Azure/bicep) is "Bicep is a declarative language for
> describing and deploying Azure resources". Does Bicep really need to be
> part of Emacs core? Couldn't it be added to ELPA instead?
Indeed.

And core developers who want to help with developing packages like bicep-ts-mode should really have gotten familiar with contributing to ELPA by now.

[-- Attachment #2: Type: text/html, Size: 795 bytes --]

Re: Ada-mode to be abandoned?

[Stefan Kangas]

Daniel Mendler via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> Also, recently there has also been a
> discussion to add a `bicep-ts-mode' to Emacs core, with the argument
> being that VSCode supports it. Makes sense, it is a Microsoft product to
> help using Microsoft products. The description of Bicep on Github
> (https://github.com/Azure/bicep) is "Bicep is a declarative language for
> describing and deploying Azure resources". Does Bicep really need to be
> part of Emacs core? Couldn't it be added to ELPA instead?

I think we should be sympathetic to arguments such as the above, yes,
but why not ask this question in the Bicep thread instead?  :-)

Re: Ada-mode to be abandoned?

[Philip Kaludercic]

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?

For me it is usually just that it is easier for a newcomer to get stuff
working, without having to deal with package management, which can be a
bother when working offline or in isolated environments.  TBH
tree-sitter complicates this somewhat, because the grammars are not
installed along with Emacs or by the system, but that is a different
issue.

> ELPA is just one 'M-x package-install' away.
>
> And Ada is niche enough that even the argument of having the popular
> languages supported OOtB doesn't work.

There are plenty of languages that are niche and supported OOtB,
especially since the introduction of tree-sitter (I for example am not
familiar with "heex").  If I were to consider helping out with
maintaining the major mode -- where my main disinclination is just the
lack of experience I have with Ada -- I'd prefer to maintain it inside
the core, because if nothing else it makes it easier for others to help
out with bugs/mistakes and use the newest features.

Either way, the current state of `ada-mode' is in my experience in no
way satisfactory, and I believe that this kind of issue is less likely
to happen inside the core.

-- 
Philip Kaludercic

Re: Ada-mode to be abandoned?

[Daniel Mendler via Emacs development discussions.]

Philip Kaludercic <philipk@posteo.net> writes:

>> ELPA is just one 'M-x package-install' away.
>>
>> And Ada is niche enough that even the argument of having the popular
>> languages supported OOtB doesn't work.
>
> There are plenty of languages that are niche and supported OOtB,
> especially since the introduction of tree-sitter (I for example am not
> familiar with "heex").  If I were to consider helping out with
> maintaining the major mode -- where my main disinclination is just the
> lack of experience I have with Ada -- I'd prefer to maintain it inside
> the core, because if nothing else it makes it easier for others to help
> out with bugs/mistakes and use the newest features.

I don't see plenty of new TS modes for niche languages in Emacs.
`heex-ts-mode' is the only one which I am not familiar with and it
belongs to the `elixir-ts-mode'. Elixir itself seems to be widely used.
Ada support in core may be reasonable, given the support in the GNU
compiler and given that it is an established, standardized language. I
don't see the same arguments for a `bicep-ts-mode'.

Daniel

Re: Ada-mode to be abandoned?

[Dmitry Gutov]

On 07/01/2024 18:26, Philip Kaludercic 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?
> 
> For me it is usually just that it is easier for a newcomer to get stuff
> working, without having to deal with package management, which can be a
> bother when working offline or in isolated environments.

This can be argued for just about any bit of Elisp code, but we don't 
want all the universe inside the Emacs repo, do we?

> TBH
> tree-sitter complicates this somewhat, because the grammars are not
> installed along with Emacs or by the system, but that is a different
> issue.

tree-sitter major modes indeed have versioning issues which could be 
easier to solve if they were distributed through ELPA.

>> ELPA is just one 'M-x package-install' away.
>>
>> And Ada is niche enough that even the argument of having the popular
>> languages supported OOtB doesn't work.
> 
> There are plenty of languages that are niche and supported OOtB,
> especially since the introduction of tree-sitter (I for example am not
> familiar with "heex").

I'm happy to agree that HEEx (as well as Elixir itself) are fringe 
enough and could go into ELPA as well. Especially considering that 
elixir-ts-mode's development is largely led externally, with most of the 
discussions led on Github and Discord.

But those are small files with infrequent commits. Much smaller than the 
Ada-mode package.

> If I were to consider helping out with
> maintaining the major mode -- where my main disinclination is just the
> lack of experience I have with Ada -- I'd prefer to maintain it inside
> the core, because if nothing else it makes it easier for others to help
> out with bugs/mistakes and use the newest features.

Again, something that applies to just about any Elisp.

> Either way, the current state of `ada-mode' is in my experience in no
> way satisfactory, and I believe that this kind of issue is less likely
> to happen inside the core.

Perhaps you just wanted to pick it up from where it was left off? It has 
an existing project infrastructure.

But from Stephen's description of the recommended future direction 
(migration to tree-sitter and LSP), it doesn't sound like a walk in the 
park. That would likely imply a redesign of most core features in the 
package.

Re: Ada-mode to be abandoned?

[Daniel Mendler via Emacs development discussions.]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 07/01/2024 18:26, Philip Kaludercic 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?
>> For me it is usually just that it is easier for a newcomer to get stuff
>> working, without having to deal with package management, which can be a
>> bother when working offline or in isolated environments.
>
> This can be argued for just about any bit of Elisp code, but we don't want all
> the universe inside the Emacs repo, do we?

While package management may be easier, there is also a discoverability
aspect. Every added package and mode makes it a little bit more
difficult for newcomers to figure out what they want to use. Which mail
client is it going to be, which IRC client, ...? For programming
language modes the problem may not be that significant, since the modes
usually activate themselves. However the documentation still gets
inflated and one may get lost in the sea of information.

In the case of Heex I see this package header:

;;; heex-ts-mode.el --- Major mode for Heex with tree-sitter support -*- lexical-binding: t; -*-
;; ...
;; This package provides `heex-ts-mode' which is a major mode for editing
;; HEEx files that uses Tree Sitter to parse the language.

Then there is this NEWS entry:

*** New major mode 'heex-ts-mode'.
A major mode based on the tree-sitter library for editing HEEx files.

This information is not helpful for a newcomer. On the other hand if you
are already an Elixir/Heex user, it should not pose a difficulty for you
to find the appropriate packages on GNU ELPA.

Daniel

Re: Ada-mode to be abandoned?

[Stefan Kangas]

Daniel Mendler via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> In the case of Heex I see this package header:
>
> ;;; heex-ts-mode.el --- Major mode for Heex with tree-sitter support -*- lexical-binding: t; -*-
> ;; ...
> ;; This package provides `heex-ts-mode' which is a major mode for editing
> ;; HEEx files that uses Tree Sitter to parse the language.
>
> Then there is this NEWS entry:
>
> *** New major mode 'heex-ts-mode'.
> A major mode based on the tree-sitter library for editing HEEx files.
>
> This information is not helpful for a newcomer. On the other hand if you
> are already an Elixir/Heex user, it should not pose a difficulty for you
> to find the appropriate packages on GNU ELPA.

Why would newcomers be perusing NEWS?  They will just open their heex
file and see that they already have syntax highlighting.

Re: Ada-mode to be abandoned?

[Daniel Mendler via Emacs development discussions.]

Stefan Kangas <stefankangas@gmail.com> writes:

> Daniel Mendler via "Emacs development discussions."
> <emacs-devel@gnu.org> writes:
>
>> In the case of Heex I see this package header:
>>
>> ;;; heex-ts-mode.el --- Major mode for Heex with tree-sitter support -*- lexical-binding: t; -*-
>> ;; ...
>> ;; This package provides `heex-ts-mode' which is a major mode for editing
>> ;; HEEx files that uses Tree Sitter to parse the language.
>>
>> Then there is this NEWS entry:
>>
>> *** New major mode 'heex-ts-mode'.
>> A major mode based on the tree-sitter library for editing HEEx files.
>>
>> This information is not helpful for a newcomer. On the other hand if you
>> are already an Elixir/Heex user, it should not pose a difficulty for you
>> to find the appropriate packages on GNU ELPA.
>
> Why would newcomers be perusing NEWS?  They will just open their heex
> file and see that they already have syntax highlighting.

The information here could be slightly more helpful. On the other hand
every bit of added information has a small associated cost, it adds a
little noise, which makes it harder to filter out the information
relevant for the user. This mirrors the point raised by Dmitry earlier,
where he mentioned that as a developer, he has to scroll over a lot of
mails and diffs related to packages, which could also be developed and
distributed on GNU ELPA.

I don't have a particular opinion about Elixir/Heex. Keeping it in core
or on ELPA are both reasonable alternatives. From my understanding,
Elixir is not a fringe language. My opinion is different in cases like
Bicep. It has a specialised use case, promotes Azure and may also become
obsolete when Azure changes. (Sorry that I am again conflating the
discussions of Ada, Elixir and Bicep.)

If one looks at lisp/progmodes there are a few modes which seem mainly
of historical interest. While VSCode may be a good example for out of
the box support, I believe they would also drop support for something
quickly if it falls out of interest. This is not a good thing and I like
the Emacs backward compatibility story much more. But when something
gets added one probably wants to be sure that it will stay useful for a
longer time and that it is useful for a significant fraction of the
users.

Daniel

Re: Ada-mode to be abandoned?

[Eli Zaretskii]

> Cc: Philip Kaludercic <philipk@posteo.net>,  emacs-devel@gnu.org,  Stephen
>  Leake <stephen_leake@stephe-leake.org>
> Date: Sun, 07 Jan 2024 22:02:41 +0100
> From:  Daniel Mendler via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> In the case of Heex I see this package header:
> 
> ;;; heex-ts-mode.el --- Major mode for Heex with tree-sitter support -*- lexical-binding: t; -*-
> ;; ...
> ;; This package provides `heex-ts-mode' which is a major mode for editing
> ;; HEEx files that uses Tree Sitter to parse the language.
> 
> Then there is this NEWS entry:
> 
> *** New major mode 'heex-ts-mode'.
> A major mode based on the tree-sitter library for editing HEEx files.
> 
> This information is not helpful for a newcomer.

Please explain why you say this is not helpful for a newcomer.

Is it better to add treesitter modes to core?

[Stefan Kangas]

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.  I see little reason for that.
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.

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

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.

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.

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

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.

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

[Philip Kaludercic]

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.

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

[Dmitry Gutov]

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

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org,  Stephen
>  Leake <stephen_leake@stephe-leake.org>
> Date: Mon, 08 Jan 2024 06:15:07 +0000
> 
> > 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).

Alas, this solution is incomplete, because some grammar libraries
don't have releases at all.

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

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org,  Stephen
>>  Leake <stephen_leake@stephe-leake.org>
>> Date: Mon, 08 Jan 2024 06:15:07 +0000
>> 
>> > 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).
>
> Alas, this solution is incomplete, because some grammar libraries
> don't have releases at all.

Most if not all git forges should support requesting an archive for a
specific commit (basically git-archive over https).  For example, this
will provide a tarball for the current newest commit for the python
tree-sitter library:

  https://github.com/tree-sitter/tree-sitter-python/archive/4bfdd9033a2225cc95032ce77066b7aeca9e2efc.tar.gz

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: dmitry@gutov.dev,  stefankangas@gmail.com,  emacs-devel@gnu.org,
>   stephen_leake@stephe-leake.org
> Date: Tue, 09 Jan 2024 19:27:50 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org,  Stephen
> >>  Leake <stephen_leake@stephe-leake.org>
> >> Date: Mon, 08 Jan 2024 06:15:07 +0000
> >> 
> >> > 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).
> >
> > Alas, this solution is incomplete, because some grammar libraries
> > don't have releases at all.
> 
> Most if not all git forges should support requesting an archive for a
> specific commit (basically git-archive over https).  For example, this
> will provide a tarball for the current newest commit for the python
> tree-sitter library:
> 
>   https://github.com/tree-sitter/tree-sitter-python/archive/4bfdd9033a2225cc95032ce77066b7aeca9e2efc.tar.gz

I was responding to the suggestion to download release tarballs.

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

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: dmitry@gutov.dev,  stefankangas@gmail.com,  emacs-devel@gnu.org,
>>   stephen_leake@stephe-leake.org
>> Date: Tue, 09 Jan 2024 19:27:50 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org,  Stephen
>> >>  Leake <stephen_leake@stephe-leake.org>
>> >> Date: Mon, 08 Jan 2024 06:15:07 +0000
>> >> 
>> >> > 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).
>> >
>> > Alas, this solution is incomplete, because some grammar libraries
>> > don't have releases at all.
>> 
>> Most if not all git forges should support requesting an archive for a
>> specific commit (basically git-archive over https).  For example, this
>> will provide a tarball for the current newest commit for the python
>> tree-sitter library:
>> 
>>   https://github.com/tree-sitter/tree-sitter-python/archive/4bfdd9033a2225cc95032ce77066b7aeca9e2efc.tar.gz
>
> I was responding to the suggestion to download release tarballs.

Then I misunderstood you, my argument is just that we could avoid
grammar versioning issues by fetching specific revisions (be it by
commits or by releases), and that we don't even have to use git for
that.

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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: dmitry@gutov.dev,  stefankangas@gmail.com,  emacs-devel@gnu.org,
>   stephen_leake@stephe-leake.org
> Date: Tue, 09 Jan 2024 20:21:02 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Cc: dmitry@gutov.dev,  stefankangas@gmail.com,  emacs-devel@gnu.org,
> >>   stephen_leake@stephe-leake.org
> >> Date: Tue, 09 Jan 2024 19:27:50 +0000
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> From: Philip Kaludercic <philipk@posteo.net>
> >> >> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org,  Stephen
> >> >>  Leake <stephen_leake@stephe-leake.org>
> >> >> Date: Mon, 08 Jan 2024 06:15:07 +0000
> >> >> 
> >> >> > 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).
> >> >
> >> > Alas, this solution is incomplete, because some grammar libraries
> >> > don't have releases at all.
> >> 
> >> Most if not all git forges should support requesting an archive for a
> >> specific commit (basically git-archive over https).  For example, this
> >> will provide a tarball for the current newest commit for the python
> >> tree-sitter library:
> >> 
> >>   https://github.com/tree-sitter/tree-sitter-python/archive/4bfdd9033a2225cc95032ce77066b7aeca9e2efc.tar.gz
> >
> > I was responding to the suggestion to download release tarballs.
> 
> Then I misunderstood you, my argument is just that we could avoid
> grammar versioning issues by fetching specific revisions (be it by
> commits or by releases), and that we don't even have to use git for
> that.

With that method, how do we know which revisions are good for us to
recommend them?  If a grammar library has releases, then its
developers already provide us with "stable" versions, but if they
don't, how do we know?

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

[Stefan Kangas]

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.

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

[Dmitry Gutov]

On 09/01/2024 07:20, Stefan Kangas 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.
> 
> 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.

That seems like the wrong positioning of the cart and the horse, IMHO. 
As we've observed, moving things out of the core is *hard*.

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

It's difficult for me to say, since I'm not really proficient in Vim, so 
whenever I tried to use it with Ruby, it never quite worked.

Reading the code, it seems one of the most complex ones, though. It even 
has some sort of basic completion using external program. But FWIW it 
doesn't look like it'll do much in any non-trivial project, and as for 
syntax highlighing and indentation, I think we're ahead, feature-wise.

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

I'm pretty sure we would have one somewhere, if not in-tree, for the 
vast majority of cases.

>>> 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 think it will be a good idea to have someone check out the ada-ts-mode 
I linked to previously in this thread, and maybe talk to the author 
about adding it to ELPA (GNU or NonGNU), if no major problems come up.

So far it looks like it has very little users (judging by the numbers of 
stars and open/closed issues - which is zero), that's kind of sad.

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

Agreed.

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

[Dmitry Gutov]

Sorry,

On 09/01/2024 19:50, Dmitry Gutov wrote:
> Reading the code, it seems one of the most complex ones, though. It even 
                   ^
                    of ruby.vim

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

[Stefan Kangas]

Dmitry Gutov <dmitry@gutov.dev> writes:

>> 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.
>
> That seems like the wrong positioning of the cart and the horse, IMHO.

I suggest that, at least the way things stand, it would be desirable to
have the basic programming modes available in core, for the top N
languages.  There's also no significant drawback to doing so.

If we make it substantially easier to install extensions and customize
Emacs in the future, then this might turn out to be less important.  We
will then adapt our way of working to that reality.

This seems to me like exactly the right way to position our horse and
cart.

> As we've observed, moving things out of the core is *hard*.

I propose that this consideration should not be decisive for how we
proceed.  If the current situation is not ideal, it's not horrible
either.

We can find better ways of doing things (e.g. distributing GNU ELPA
packages with Emacs), but whatever we do later, it doesn't seem urgent
to avoid adding things to core right now.

>> For some of the things listed there, we don't even have a mode.
>
> I'm pretty sure we would have one somewhere, if not in-tree, for the
> vast majority of cases.

(I couldn't find one for /etc/fstab, FWIW.  That may or may not be a
silly example, but OTOH what's not to like about syntax highlighting.
Maybe there were better examples too, I can't remember.)

> I think it will be a good idea to have someone check out the ada-ts-mode
> I linked to previously in this thread, and maybe talk to the author
> about adding it to ELPA (GNU or NonGNU), if no major problems come up.
>
> So far it looks like it has very little users (judging by the numbers of
> stars and open/closed issues - which is zero), that's kind of sad.

Philip, what do you think about this?

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 9 Jan 2024 10:59:50 -0800
> Cc: Stephen Leake <stephen_leake@stephe-leake.org>
> 
> I couldn't find one for /etc/fstab, FWIW.

We have etc-fstab-generic-mode in generic-x.el.

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

[Dmitry Gutov]

On 09/01/2024 21:51, Eli Zaretskii wrote:
>> From: Stefan Kangas<stefankangas@gmail.com>
>> Date: Tue, 9 Jan 2024 10:59:50 -0800
>> Cc: Stephen Leake<stephen_leake@stephe-leake.org>
>>
>> I couldn't find one for /etc/fstab, FWIW.
> We have etc-fstab-generic-mode in generic-x.el.

And FWIW fstab opens in conf-space-mode here.

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

[Stefan Kangas]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 09/01/2024 21:51, Eli Zaretskii wrote:
>>> From: Stefan Kangas<stefankangas@gmail.com>
>>> Date: Tue, 9 Jan 2024 10:59:50 -0800
>>> Cc: Stephen Leake<stephen_leake@stephe-leake.org>
>>>
>>> I couldn't find one for /etc/fstab, FWIW.
>> We have etc-fstab-generic-mode in generic-x.el.

Ah, right.  So ours was just not as good as theirs.

I can't remember which vim mode I saw that we didn't have, then.

> And FWIW fstab opens in conf-space-mode here.

Bug?

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

[Dmitry Gutov]

On 10/01/2024 08:27, Stefan Kangas wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
> 
>> On 09/01/2024 21:51, Eli Zaretskii wrote:
>>>> From: Stefan Kangas<stefankangas@gmail.com>
>>>> Date: Tue, 9 Jan 2024 10:59:50 -0800
>>>> Cc: Stephen Leake<stephen_leake@stephe-leake.org>
>>>>
>>>> I couldn't find one for /etc/fstab, FWIW.
>>> We have etc-fstab-generic-mode in generic-x.el.
> Ah, right.  So ours was just not as good as theirs.
> 
> I can't remember which vim mode I saw that we didn't have, then.
> 
>> And FWIW fstab opens in conf-space-mode here.
> Bug?

Not sure: its conf-space-mode entry in auto-mode-alist seems intentional.

etc-fstab-generic-mode starts to get used if I (require 'generic-x), 
however.

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

[Stefan Kangas]

Dmitry Gutov <dmitry@gutov.dev> writes:

> etc-fstab-generic-mode starts to get used if I (require 'generic-x),
> however.

IIUC, that's the expected behaviour.

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

[Dmitry Gutov]

On 10/01/2024 14:03, Stefan Kangas wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
> 
>> etc-fstab-generic-mode starts to get used if I (require 'generic-x),
>> however.
> IIUC, that's the expected behaviour.

etc-fstab-generic-mode has better highlighting, though, so I don't know 
whether the current state of affairs should be considered a problem or not.

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

[Stefan Kangas]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 10/01/2024 14:03, Stefan Kangas wrote:
>> Dmitry Gutov<dmitry@gutov.dev>  writes:
>>
>>> etc-fstab-generic-mode starts to get used if I (require 'generic-x),
>>> however.
>> IIUC, that's the expected behaviour.
>
> etc-fstab-generic-mode has better highlighting, though, so I don't know
> whether the current state of affairs should be considered a problem or not.

I think we should just load generic-x modes unconditionally, but we
haven't been able to find consensus around that so far.

Previous discussions here:
https://lists.gnu.org/r/emacs-devel/2021-01/msg01403.html
https://lists.gnu.org/r/emacs-devel/2021-02/msg00546.html

Modes in generic-x.el (was: Is it better to add treesitter modes to core?)

[Peter Oliver]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

On Wed, 10 Jan 2024, Stefan Kangas wrote:

> Dmitry Gutov <dmitry@gutov.dev> writes:
>
>> etc-fstab-generic-mode starts to get used if I (require 'generic-x),
>> however.
>
> IIUC, that's the expected behaviour.

Could/should we autoload the modes in generic-x.el?  I’m not sure how a user would know to require it to get the miscellaneous modes it contains.

-- 
Peter Oliver

Re: Modes in generic-x.el (was: Is it better to add treesitter modes to core?)

[Eli Zaretskii]

> Date: Wed, 10 Jan 2024 12:35:27 +0000 (GMT)
> From: Peter Oliver <p.d.oliver@mavit.org.uk>
> 
> On Wed, 10 Jan 2024, Stefan Kangas wrote:
> 
> > Dmitry Gutov <dmitry@gutov.dev> writes:
> >
> >> etc-fstab-generic-mode starts to get used if I (require 'generic-x),
> >> however.
> >
> > IIUC, that's the expected behaviour.
> 
> Could/should we autoload the modes in generic-x.el?

No, we shouldn't.  generic-x comes with a lot of modes, and setting up
the ones you want activated requires manual tinkering.

If we think some mode from there is very useful, we should move it out
to a separate file, and then we can autoload it (assuming moving modes
from generic-x is easy).

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 10 Jan 2024 04:03:00 -0800
> Cc: philipk@posteo.net, emacs-devel@gnu.org, stephen_leake@stephe-leake.org
> 
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
> > etc-fstab-generic-mode starts to get used if I (require 'generic-x),
> > however.
> 
> IIUC, that's the expected behaviour.

Yes.  We don't activate modes in generic-x.el unless the user
explicitly loads it.

Re: Ada-mode to be abandoned?

[Fernando Oleo Blanco]

Hi Philip and the larger Emacs community,

thank you for bringing this topic up. Stephen also posted this message 
to Ada-Lang.io [1], which have become sort of a home for the Adaists. 
Sadly nobody there seemed to be willing to take over maintainership. 
Nonetheless, I would like to say that there are still a few of us that 
do use this mode and we are glad that we have it :)

If I am allowed to express my personal opinion here...

ada-mode, as it currently stands, requires compiling some Ada code in 
order for it to work. It comes with some helper scripts for that task. 
However, the experience to get it working is not as nice as with other 
packages due to the compilation step. One cannot simply install it and 
just M-x ada-mode... This nuisance is compounded by the fact that 
GNAT/GCC-Ada tends to break old code (for the better, as it becomes even 
more reliable) and ada-mode sometimes requires modern compilers to work. 
It also has some external dependencies that are installed with the 
installer script, which, imho, is not that nice...

I do not want the paragraph above to be understood as a criticism to the 
current state of things. We have what we have and that is great, but I 
want to point out major improvement points as I see them.

I personally would prefer to see a tree-sitter/pure-elisp 
implementation, which could make the maintenance burden smaller and 
improve the user experience as Stephen points out in his list. Then, as 
he also says, we have an LSP nowdays, which is nice; but a dedicated 
ada-mode is still very important.

If anybody needs help testing ada-mode, I am willing to do so as I have 
done a couple of times.

Best regards,
Fernando Oleo Blanco

[1] https://forum.ada-lang.io/t/gnu-emacs-ada-mode-passing-the-torch/518

P.S: I am not volunteering as my time and knowledge of the subject are 
very limited...

On 1/7/24 13:34, Philip Kaludercic wrote:
> 
> I recently came across this message on the ada-mode-users' mailing list:
> 
>    https://lists.nongnu.org/archive/html/ada-mode-users/2023-11/msg00000.html
> 
> Stephen (the maintainer, in the CC's) indicates that he would like to
> retire from maintenance, which might mean that the package could become
> abandon-ware.
> 
> One note he makes is that the current implementation could be
> simplified, by just using tree-sitter, instead of the approach that
> makes use of a custom parser:
> 
> --8<---------------cut here---------------start------------->8---
> 2) Drop the wisitoken parser generator and runtime, use tree-sitter
>     instead. This requires writing a wrapper for tree-sitter to match
>     the wisitoken syntax-tree API; then the current wisi indentation
>     code can be used.
> 
>     This maintains all of the ada-mode features, while reducing the
>     maintenance burden significantly.
> 
>     I believe the tree-sitter error correction is less powerful than
>     wisitoken, but it would be interesting to see if that matters in
>     practice.
> --8<---------------cut here---------------end--------------->8---
> 
> 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?  I would be glad to help out, since I've been interested in
> working with Ada for a while but never got it to work, I have just been
> struggling with understanding how `treesit-font-lock-rules' is supposed
> to be used, so some help would be appreciated.
> 
> --
> Philip Kaludercic
> 

Re: Ada-mode to be abandoned?

[Philip Kaludercic]

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

> ada-mode, as it currently stands, requires compiling some Ada code in 
> order for it to work. It comes with some helper scripts for that task. 
> However, the experience to get it working is not as nice as with other 
> packages due to the compilation step. One cannot simply install it and 
> just M-x ada-mode... 

On this point, I believe it could be improved if `ada-mode' could check
if the necessary programs are installed, and otherwise try to build them
on its own (as other packages do, e.g. pdf-tools).  Playing around with
ada-mode today, I just got an error message after error message, having
to guess what packages, dependencies and package managers to install,
that I ended up writing my code in fundamental mode, which I find sad.

-- 
Philip Kaludercic

Re: Ada-mode to be abandoned?

[Fernando Oleo Blanco]

On 1/7/24 17:48, Philip Kaludercic wrote:

> On this point, I believe it could be improved if `ada-mode' could check
> if the necessary programs are installed, and otherwise try to build them
> on its own (as other packages do, e.g. pdf-tools).  Playing around with
> ada-mode today, I just got an error message after error message, having
> to guess what packages, dependencies and package managers to install,
> that I ended up writing my code in fundamental mode, which I find sad.
> 
> --
> Philip Kaludercic

I believe when the user tries to run ada-mode a message about compiling 
pops up, but I have not done that in a while. The documentation explains 
the process well. Though I do not blame you for this experience. As I 
said in my previous message, the users expect a package/major-mode to 
just work after installation; and that is how things should be. If you 
need help, just let me know and I will try my best to aid you.

On a related topic, there is already an ada-tree-sitter grammar system 
available [1], in case someone did not know and just in case this makes 
things easier.

Best regards,
Fer

[1] https://github.com/briot/tree-sitter-ada