Adding major or popular language modes to Emacs distribution

Adding major or popular language modes to Emacs distribution

[Yuchen Pei]

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

Hello,

I notice some glaring omissions of modes supporting major / 
popular languages like php, haskell and wikitext in Emacs, though 
there are widely used versions available externally as packages.

I feel it is important that Emacs support these languages 
natively.

What is the process of adding these modes?  My understanding is:

1. Ask the maintainer of a mode to contribute the mode to Emacs.
2. If for some reason the maintainer is unable or unwilling to add 
the mode, someone writes the mode and contribute to Emacs.

In step 2, is it conventional to add the mode to GNU ELPA first, 
before moving it into Emacs itself?

I am asking because I am interested in working on some of these 
modes.

-- 
Best,
Yuchen

PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
           <https://ypei.me/assets/ypei-pubkey.txt>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 243 bytes --]

Re: Adding major or popular language modes to Emacs distribution

[Philip Kaludercic]

Yuchen Pei <hi@ypei.me> writes:

> Hello,
>
> I notice some glaring omissions of modes supporting major / popular
> languages like php, haskell and wikitext in Emacs, though there are
> widely used versions available externally as packages.

See the thread "Re: NonGNU ELPA work" from today: I submitted patches
for NonGNU ELPA, the repository that has been enabled for Emacs 28+,
adding new major modes, so that they can be installed without any
further configuration.

> I feel it is important that Emacs support these languages natively.

Why natively? With packages like gnu-elpa, the user can be notified when
a major mode exists for a file they have opened. The advantage is that
bug-fixes and improvements are not tied to Emacs releases but can happen
concurrently. The disadvantage is that it requires an internet
connection.

> What is the process of adding these modes?  My understanding is:
>
> 1. Ask the maintainer of a mode to contribute the mode to Emacs.

And any significant contributor have to sign the FSF copyright
agreement.

> 2. If for some reason the maintainer is unable or unwilling to add the
> mode, someone writes the mode and contribute to Emacs.
>
> In step 2, is it conventional to add the mode to GNU ELPA first,
> before moving it into Emacs itself?
>
> I am asking because I am interested in working on some of these modes.

-- 
	Philip Kaludercic

Re: Adding major or popular language modes to Emacs distribution

[Yuchen Pei]

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


Philip Kaludercic <philipk@posteo.net> writes:

> Yuchen Pei <hi@ypei.me> writes:
>
>> Hello,
>>
>> I notice some glaring omissions of modes supporting major / 
>> popular
>> languages like php, haskell and wikitext in Emacs, though there 
>> are
>> widely used versions available externally as packages.
>
> See the thread "Re: NonGNU ELPA work" from today: I submitted 
> patches
> for NonGNU ELPA, the repository that has been enabled for Emacs 
> 28+,
> adding new major modes, so that they can be installed without 
> any
> further configuration.

I'm aware of NonGNU ELPA and use it, thanks for adding packages 
there.  But I'm not sure it can substitute Emacs itself.

>
>> I feel it is important that Emacs support these languages 
>> natively.
>
> Why natively? With packages like gnu-elpa, the user can be 
> notified when
> a major mode exists for a file they have opened. The advantage 
> is that
> bug-fixes and improvements are not tied to Emacs releases but 
> can happen
> concurrently. The disadvantage is that it requires an internet
> connection.

This makes sense.  But does this mean if I want to add new 
language modes it should go to GNU ELPA rather than Emacs itself?

>
>> What is the process of adding these modes?  My understanding 
>> is:
>>
>> 1. Ask the maintainer of a mode to contribute the mode to 
>> Emacs.
>
> And any significant contributor have to sign the FSF copyright
> agreement.

I acknowledge this could be a reason why some packages don't make 
their way to GNU ELPA or Emacs, but it shouldn't be a reason why 
new modes satisfying the criteria shouldn't be added to GNU ELPA 
or Emacs.

>
>> 2. If for some reason the maintainer is unable or unwilling to 
>> add the
>> mode, someone writes the mode and contribute to Emacs.
>>
>> In step 2, is it conventional to add the mode to GNU ELPA 
>> first,
>> before moving it into Emacs itself?
>>
>> I am asking because I am interested in working on some of these 
>> modes.


-- 
Best,
Yuchen

PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
           <https://ypei.me/assets/ypei-pubkey.txt>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 243 bytes --]

Re: Adding major or popular language modes to Emacs distribution

[Arthur Miller]

Yuchen Pei <hi@ypei.me> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Yuchen Pei <hi@ypei.me> writes:
>>
>>> Hello,
>>>
>>> I notice some glaring omissions of modes supporting major / popular
>>> languages like php, haskell and wikitext in Emacs, though there are
>>> widely used versions available externally as packages.
>>
>> See the thread "Re: NonGNU ELPA work" from today: I submitted patches
>> for NonGNU ELPA, the repository that has been enabled for Emacs 28+,
>> adding new major modes, so that they can be installed without any
>> further configuration.
>
> I'm aware of NonGNU ELPA and use it, thanks for adding packages there.  But I'm
> not sure it can substitute Emacs itself.

Code added to Emacs has to follow certain rules about license and
quality. Reasons why the code you ask for is not in Emacs might be several, but
I would tip probably because the author(s) didn't signed the FSF copyright
assigment, or they simply didn't cared themselves to submit their packages into
Emacs.

Also even if you think a package is very useful, it might not be useful to
everyone. I would prefer to even refactor some of built-in packages into gnu
elpa instead of having them all in Emacs.

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> From: Yuchen Pei <hi@ypei.me>
> Date: Sat, 28 Aug 2021 09:04:40 +1000
> 
> I notice some glaring omissions of modes supporting major / 
> popular languages like php, haskell and wikitext in Emacs, though 
> there are widely used versions available externally as packages.
> 
> I feel it is important that Emacs support these languages 
> natively.

I agree.

> What is the process of adding these modes?  My understanding is:
> 
> 1. Ask the maintainer of a mode to contribute the mode to Emacs.
> 2. If for some reason the maintainer is unable or unwilling to add 
> the mode, someone writes the mode and contribute to Emacs.

Yes, that's the general idea.

> In step 2, is it conventional to add the mode to GNU ELPA first, 
> before moving it into Emacs itself?

I see no need to go via ELPA for stuff we believe should be bundled
with Emacs.  If we consider those languages to be important enough to
support OOTB, Emacs should come with them built-in.

> I am asking because I am interested in working on some of these 
> modes.

Thanks in advance.

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Date: Fri, 27 Aug 2021 23:12:41 +0000
> Cc: Emacs Devel mailing list <emacs-devel@gnu.org>
> 
> > I notice some glaring omissions of modes supporting major / popular
> > languages like php, haskell and wikitext in Emacs, though there are
> > widely used versions available externally as packages.
> 
> See the thread "Re: NonGNU ELPA work" from today: I submitted patches
> for NonGNU ELPA, the repository that has been enabled for Emacs 28+,
> adding new major modes, so that they can be installed without any
> further configuration.

That's not the same as having these come with Emacs in the first
place.

> > I feel it is important that Emacs support these languages natively.
> 
> Why natively? With packages like gnu-elpa, the user can be notified when
> a major mode exists for a file they have opened. The advantage is that
> bug-fixes and improvements are not tied to Emacs releases but can happen
> concurrently. The disadvantage is that it requires an internet
> connection.

It sounds like your vision of the role of the ELPA repositories vs
what comes bundled with Emacs is different from the current project's
vision.  In which case it would help if in the future you mentioned
that you don't speak for the project, to make that clear to people who
don't necessarily know who is who in the project.

> > What is the process of adding these modes?  My understanding is:
> >
> > 1. Ask the maintainer of a mode to contribute the mode to Emacs.
> 
> And any significant contributor have to sign the FSF copyright
> agreement.

Right.

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Sat, 28 Aug 2021 04:38:42 +0200
> Cc: Philip Kaludercic <philipk@posteo.net>,
>  Emacs Devel mailing list <emacs-devel@gnu.org>
> 
> Also even if you think a package is very useful, it might not be useful to
> everyone. I would prefer to even refactor some of built-in packages into gnu
> elpa instead of having them all in Emacs.

That's not the current vision of the project.  We want all the
features that are important to have in Emacs OOTB to be bundled.  And
support for popular programming languages was always a very important
built-in feature of Emacs.

So yes, we want that to be in core, not in ELPA.

Re: Adding major or popular language modes to Emacs distribution

[Qiantan Hong]

On this spirit, should we try to bundle in some more “IDE” like
features/packages rather than just file modes?
I could speak for SLIME or SLY, which is practically used by every
Common Lisp programmers (practically everyone of them use Emacs).
They’re both licensed under Public Domain.

> On Aug 27, 2021, at 11:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Sat, 28 Aug 2021 04:38:42 +0200
>> Cc: Philip Kaludercic <philipk@posteo.net>,
>> Emacs Devel mailing list <emacs-devel@gnu.org>
>> 
>> Also even if you think a package is very useful, it might not be useful to
>> everyone. I would prefer to even refactor some of built-in packages into gnu
>> elpa instead of having them all in Emacs.
> 
> That's not the current vision of the project.  We want all the
> features that are important to have in Emacs OOTB to be bundled.  And
> support for popular programming languages was always a very important
> built-in feature of Emacs.
> 
> So yes, we want that to be in core, not in ELPA.
> 

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> From: Qiantan Hong <qhong@mit.edu>
> Date: Sat, 28 Aug 2021 11:34:46 +0000
> Cc: Philip Kaludercic <philipk@posteo.net>, "hi@ypei.me" <hi@ypei.me>,
>  Arthur Miller <arthur.miller@live.com>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> On this spirit, should we try to bundle in some more “IDE” like
> features/packages rather than just file modes?

In general, yes.  We imported parts of CEDET for that, although that
didn't (yet) get us a decent IDE.

> I could speak for SLIME or SLY, which is practically used by every
> Common Lisp programmers (practically everyone of them use Emacs).
> They’re both licensed under Public Domain.

Not sure what you are proposing.  If their developers would like to
suggest those packages for inclusion in Emacs and to be developed as
part of Emacs, we could consider that.  But they need to want to do
that, we cannot take over those packages, or at least that would be
undesirable, if not improper.

Re: Adding major or popular language modes to Emacs distribution

[Stefan Monnier]

> This makes sense.  But does this mean if I want to add new language modes it
> should go to GNU ELPA rather than Emacs itself?

As a former Emacs maintainer and as de-facto maintainer of (Non)GNU
ELPA, I think the answer here is "yes", basically.

There are some packages which we want to include in Emacs itself, either
because they're expected to be used by a large fraction of Emacs users,
or because they're used by other packages included in Emacs, but for
most of the rest we prefer to accept new packages into GNU ELPA than
into Emacs, because it offers more flexibility (e.g. in terms of
release schedules).

AFAIK there are still plans to have some amount of integration between
Emacs and GNU ELPA where some GNU ELPA packages would get included in
Emacs releases, thus blurring the line between the two a bit more.
This said, these plans have been in existence for several years, so
don't hold your breath :-(


        Stefan

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Philip Kaludercic <philipk@posteo.net>,  Emacs Devel mailing list
>  <emacs-devel@gnu.org>
> Date: Sat, 28 Aug 2021 09:14:55 -0400
> 
> > This makes sense.  But does this mean if I want to add new language modes it
> > should go to GNU ELPA rather than Emacs itself?
> 
> As a former Emacs maintainer and as de-facto maintainer of (Non)GNU
> ELPA, I think the answer here is "yes", basically.
> 
> There are some packages which we want to include in Emacs itself, either
> because they're expected to be used by a large fraction of Emacs users,
> or because they're used by other packages included in Emacs, but for
> most of the rest we prefer to accept new packages into GNU ELPA than
> into Emacs, because it offers more flexibility (e.g. in terms of
> release schedules).

When you say "we prefer" here you mean you personally, right?  Because
there's no such project-wide policy, AFAICT, and I at least don't
agree.

Re: Adding major or popular language modes to Emacs distribution

[Dmitry Gutov]

On 28.08.2021 16:37, Eli Zaretskii wrote:
> When you say "we prefer" here you mean you personally, right?  Because
> there's no such project-wide policy, AFAICT, and I at least don't
> agree.

There is a known existing disagreement on this issue among contributors.

Re: Adding major or popular language modes to Emacs distribution

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Fri, 27 Aug 2021 23:12:41 +0000
>> Cc: Emacs Devel mailing list <emacs-devel@gnu.org>
>> 
>> > I notice some glaring omissions of modes supporting major / popular
>> > languages like php, haskell and wikitext in Emacs, though there are
>> > widely used versions available externally as packages.
>> 
>> See the thread "Re: NonGNU ELPA work" from today: I submitted patches
>> for NonGNU ELPA, the repository that has been enabled for Emacs 28+,
>> adding new major modes, so that they can be installed without any
>> further configuration.
>
> That's not the same as having these come with Emacs in the first
> place.

Of course, I agree that it is preferable, but how realistic is it
currently. While reviewing a lot of popular packages (php-mode,
haskell-mode, ...) it seems improbable to gather all the copyright
assignments even necessary to transfer the code into ELPA.

Another issue that already exists with major modes included in Emacs is
that they often differ in insignificant but annoying ways. When
comparing the binding C-c C-c in python-mode, scheme-mode and
prolog-mode, one respectively finds a send-buffer, compile-defun command
and a keymap. I can only imagine that with more and more languages in
Emacs itself, this issue would get worse (this of course isn't solved by
distributing the code in ELPA, but one would imagine that core-code
should be a bit more consistent). It might make sense to extend
prog-mode by additional generic modes like compiled-prog-mode,
interpreted-prog-mode, interactive-prog-mode, etc. to make it easier to
define and customize language modes.

>> > I feel it is important that Emacs support these languages natively.
>> 
>> Why natively? With packages like gnu-elpa, the user can be notified when
>> a major mode exists for a file they have opened. The advantage is that
>> bug-fixes and improvements are not tied to Emacs releases but can happen
>> concurrently. The disadvantage is that it requires an internet
>> connection.
>
> It sounds like your vision of the role of the ELPA repositories vs
> what comes bundled with Emacs is different from the current project's
> vision.  In which case it would help if in the future you mentioned
> that you don't speak for the project, to make that clear to people who
> don't necessarily know who is who in the project.

Sincerely sorry about that! I'll keep that in mind and try to avoid
confusion between my hopes and the actual project line.

-- 
	Philip Kaludercic

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> Cc: philipk@posteo.net, hi@ypei.me, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 28 Aug 2021 16:42:43 +0300
> 
> On 28.08.2021 16:37, Eli Zaretskii wrote:
> > When you say "we prefer" here you mean you personally, right?  Because
> > there's no such project-wide policy, AFAICT, and I at least don't
> > agree.
> 
> There is a known existing disagreement on this issue among contributors.

If a contributor _wants_ to have the package in ELPA, that's his/her
prerogative, which should be respected.  But in this particular case
the contributor asked about our preferences, and that was what my
response was about.

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: hi@ypei.me,  emacs-devel@gnu.org
> Date: Sat, 28 Aug 2021 13:45:41 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> See the thread "Re: NonGNU ELPA work" from today: I submitted patches
> >> for NonGNU ELPA, the repository that has been enabled for Emacs 28+,
> >> adding new major modes, so that they can be installed without any
> >> further configuration.
> >
> > That's not the same as having these come with Emacs in the first
> > place.
> 
> Of course, I agree that it is preferable, but how realistic is it
> currently.

If that requirement cannot be met, then we will be unable to have the
package in Emacs, of course.  In that case, if the OP would like to
write a replacement from scratch, we'd consider importing that
instead; or, failing that, will have the package in non-GNU ELPA.

> Another issue that already exists with major modes included in Emacs is
> that they often differ in insignificant but annoying ways. When
> comparing the binding C-c C-c in python-mode, scheme-mode and
> prolog-mode, one respectively finds a send-buffer, compile-defun command
> and a keymap. I can only imagine that with more and more languages in
> Emacs itself, this issue would get worse (this of course isn't solved by
> distributing the code in ELPA, but one would imagine that core-code
> should be a bit more consistent). It might make sense to extend
> prog-mode by additional generic modes like compiled-prog-mode,
> interpreted-prog-mode, interactive-prog-mode, etc. to make it easier to
> define and customize language modes.

We should definitely make the PL modes more consistent wrt the basic
key bindings.  But having sch packages in ELPA doesn't help solving
this problem, because it's an orthogonal issue, right?

> > It sounds like your vision of the role of the ELPA repositories vs
> > what comes bundled with Emacs is different from the current project's
> > vision.  In which case it would help if in the future you mentioned
> > that you don't speak for the project, to make that clear to people who
> > don't necessarily know who is who in the project.
> 
> Sincerely sorry about that! I'll keep that in mind and try to avoid
> confusion between my hopes and the actual project line.

Thanks; and no need to apologize.

Re: Adding major or popular language modes to Emacs distribution

[Dmitry Gutov]

On 28.08.2021 16:49, Eli Zaretskii wrote:
>> Cc:philipk@posteo.net,hi@ypei.me,emacs-devel@gnu.org
>> From: Dmitry Gutov<dgutov@yandex.ru>
>> Date: Sat, 28 Aug 2021 16:42:43 +0300
>>
>> On 28.08.2021 16:37, Eli Zaretskii wrote:
>>> When you say "we prefer" here you mean you personally, right?  Because
>>> there's no such project-wide policy, AFAICT, and I at least don't
>>> agree.
>> There is a known existing disagreement on this issue among contributors.
> If a contributor_wants_  to have the package in ELPA, that's his/her
> prerogative, which should be respected.  But in this particular case
> the contributor asked about our preferences, and that was what my
> response was about.

You stated your preferences, right?

Stefan's are different, and mine are as well (which is probably 
well-known at this point).

There are also many other proponents of "lean core", though I admit most 
of them, predictably, work on third-party packages rather than frequent 
emacs-devel.

Re: Adding major or popular language modes to Emacs distribution

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> Another issue that already exists with major modes included in Emacs is
>> that they often differ in insignificant but annoying ways. When
>> comparing the binding C-c C-c in python-mode, scheme-mode and
>> prolog-mode, one respectively finds a send-buffer, compile-defun command
>> and a keymap. I can only imagine that with more and more languages in
>> Emacs itself, this issue would get worse (this of course isn't solved by
>> distributing the code in ELPA, but one would imagine that core-code
>> should be a bit more consistent). It might make sense to extend
>> prog-mode by additional generic modes like compiled-prog-mode,
>> interpreted-prog-mode, interactive-prog-mode, etc. to make it easier to
>> define and customize language modes.
>
> We should definitely make the PL modes more consistent wrt the basic
> key bindings.  But having sch packages in ELPA doesn't help solving
> this problem, because it's an orthogonal issue, right?

Yes, I was jut mentioning that if there ever were a push to include more
major modes in Emacs, that something like this might be worth
considering.

-- 
	Philip Kaludercic

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, philipk@posteo.net, hi@ypei.me,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 28 Aug 2021 17:16:22 +0300
> 
> On 28.08.2021 16:49, Eli Zaretskii wrote:
> >> Cc:philipk@posteo.net,hi@ypei.me,emacs-devel@gnu.org
> >> From: Dmitry Gutov<dgutov@yandex.ru>
> >> Date: Sat, 28 Aug 2021 16:42:43 +0300
> >>
> >> On 28.08.2021 16:37, Eli Zaretskii wrote:
> >>> When you say "we prefer" here you mean you personally, right?  Because
> >>> there's no such project-wide policy, AFAICT, and I at least don't
> >>> agree.
> >> There is a known existing disagreement on this issue among contributors.
> > If a contributor_wants_  to have the package in ELPA, that's his/her
> > prerogative, which should be respected.  But in this particular case
> > the contributor asked about our preferences, and that was what my
> > response was about.
> 
> You stated your preferences, right?

No, I stated the current project's policy, which is still unchanged
since long ago.  It happens to be my personal preference as well, but
that's not what the OP asked about.

> Stefan's are different, and mine are as well (which is probably 
> well-known at this point).
> 
> There are also many other proponents of "lean core", though I admit most 
> of them, predictably, work on third-party packages rather than frequent 
> emacs-devel.

As long as we don't change the project-wide policy, we should talk and
act according to the existing one, when people ask about that.

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: hi@ypei.me,  emacs-devel@gnu.org
> Date: Sat, 28 Aug 2021 14:30:16 +0000
> 
> > We should definitely make the PL modes more consistent wrt the basic
> > key bindings.  But having sch packages in ELPA doesn't help solving
> > this problem, because it's an orthogonal issue, right?
> 
> Yes, I was jut mentioning that if there ever were a push to include more
> major modes in Emacs, that something like this might be worth
> considering.

To clarify, I was only talking about programming languages that are
very popular -- I think Emacs should offer those OOTB.  I didn't mean
we should necessarily have in core every possible language under the
sun.  We could discuss the less popular ones on a case by case basis.

Re: Adding major or popular language modes to Emacs distribution

[Theodor Thornhill]

On 28 August 2021 16:40:26 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: hi@ypei.me,  emacs-devel@gnu.org
>> Date: Sat, 28 Aug 2021 14:30:16 +0000
>> 
>> > We should definitely make the PL modes more consistent wrt the basic
>> > key bindings.  But having sch packages in ELPA doesn't help solving
>> > this problem, because it's an orthogonal issue, right?
>> 
>> Yes, I was jut mentioning that if there ever were a push to include more
>> major modes in Emacs, that something like this might be worth
>> considering.
>
>To clarify, I was only talking about programming languages that are
>very popular -- I think Emacs should offer those OOTB.  I didn't mean
>we should necessarily have in core every possible language under the
>sun.  We could discuss the less popular ones on a case by case basis.
>

Where does this line go? We recently added c# mode to elpa, and some people did not want it in core. I would classify that at a popular language

Theo

Re: Adding major or popular language modes to Emacs distribution

[Dmitry Gutov]

On 28.08.2021 17:37, Eli Zaretskii wrote:
>>>> There is a known existing disagreement on this issue among contributors.
>>> If a contributor_wants_  to have the package in ELPA, that's his/her
>>> prerogative, which should be respected.  But in this particular case
>>> the contributor asked about our preferences, and that was what my
>>> response was about.
>> You stated your preferences, right?
> No, I stated the current project's policy, which is still unchanged
> since long ago.  It happens to be my personal preference as well, but
> that's not what the OP asked about.

I don't remember seeing such a policy documented anywhere.

But suppose it is so. What would it take to change it?

We might hold off on having such discussion until the "ELPA bundling" 
feature is more or less ready, but it would be nice to know in advance.

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> Date: Sat, 28 Aug 2021 16:45:49 +0200
> From: Theodor Thornhill <theo@thornhill.no>
> CC: hi@ypei.me
> 
> 
> 
> On 28 August 2021 16:40:26 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Cc: hi@ypei.me,  emacs-devel@gnu.org
> >> Date: Sat, 28 Aug 2021 14:30:16 +0000
> >> 
> >> > We should definitely make the PL modes more consistent wrt the basic
> >> > key bindings.  But having sch packages in ELPA doesn't help solving
> >> > this problem, because it's an orthogonal issue, right?
> >> 
> >> Yes, I was jut mentioning that if there ever were a push to include more
> >> major modes in Emacs, that something like this might be worth
> >> considering.
> >
> >To clarify, I was only talking about programming languages that are
> >very popular -- I think Emacs should offer those OOTB.  I didn't mean
> >we should necessarily have in core every possible language under the
> >sun.  We could discuss the less popular ones on a case by case basis.
> >
> 
> Where does this line go? We recently added c# mode to elpa, and some people did not want it in core. I would classify that at a popular language

Which languages constitute the popular ones is something open to
debate, of course.  It isn't carved in stone, and I don't think there
are firm objective criteria for that.  When there's no agreement, we'd
need to discuss.

Re: Adding major or popular language modes to Emacs distribution

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If a contributor _wants_ to have the package in ELPA, that's his/her
> prerogative, which should be respected.  But in this particular case
> the contributor asked about our preferences, and that was what my
> response was about.

It's my preference for some language features, too.  Having those
available out of the box is convenient (and allows for easier
integration with the rest of Emacs).

It's pretty embarrassing that we don't have a built-in mode for PHP, for
instance (or at least it was back when PHP was popular).

But it depends on the language.  I think having the C# mode in ELPA is
fine, and there isn't much to gain in having it in Emacs core.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, philipk@posteo.net, hi@ypei.me,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 28 Aug 2021 17:46:25 +0300
> 
> On 28.08.2021 17:37, Eli Zaretskii wrote:
> >>>> There is a known existing disagreement on this issue among contributors.
> >>> If a contributor_wants_  to have the package in ELPA, that's his/her
> >>> prerogative, which should be respected.  But in this particular case
> >>> the contributor asked about our preferences, and that was what my
> >>> response was about.
> >> You stated your preferences, right?
> > No, I stated the current project's policy, which is still unchanged
> > since long ago.  It happens to be my personal preference as well, but
> > that's not what the OP asked about.
> 
> I don't remember seeing such a policy documented anywhere.

It comes from the time when there was no ELPA.  At that time, there
was no need to document it, of course.

> But suppose it is so. What would it take to change it?
> 
> We might hold off on having such discussion until the "ELPA bundling" 
> feature is more or less ready, but it would be nice to know in advance.

Yes, that's the prerequisite for these discussions, I think.  I don't
know of any others, but if anyone else does, please speak up.

Re: Adding major or popular language modes to Emacs distribution

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: hi@ypei.me,  emacs-devel@gnu.org
>> Date: Sat, 28 Aug 2021 14:30:16 +0000
>> 
>> > We should definitely make the PL modes more consistent wrt the basic
>> > key bindings.  But having sch packages in ELPA doesn't help solving
>> > this problem, because it's an orthogonal issue, right?
>> 
>> Yes, I was jut mentioning that if there ever were a push to include more
>> major modes in Emacs, that something like this might be worth
>> considering.
>
> To clarify, I was only talking about programming languages that are
> very popular -- I think Emacs should offer those OOTB.  I didn't mean
> we should necessarily have in core every possible language under the
> sun.  We could discuss the less popular ones on a case by case basis.

What I was thinking of is that some of prog modes that ship with Emacs are
frankly not very good compared to external packages, and people are anyway
downloading something else (for exapel js vs js2 or lisp vs slime/sly). It would
be nice if everything was in Emacs by default but, maybe it is better to lessen
the burden on Emacs devs themselves and point users to external package instead.

Now that we have non gnu elpa, and Stefan says it is no problem to ship someone
elses packages, maybe some good soul could package those into non gnu elpa and
Emacs could do like some other text editors, simply point users to download
needed package or download it on demand?

There was no non gnu elpa before, maybe you could revise the policy in that
light?

After this sotrom about Git and workflow has blow away of course :).

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  philipk@posteo.net,  hi@ypei.me,
>   monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sat, 28 Aug 2021 16:59:54 +0200
> 
> But it depends on the language.  I think having the C# mode in ELPA is
> fine, and there isn't much to gain in having it in Emacs core.

Agreed.  (I have no opinion about C#, so I'll defer to others here.)

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: Philip Kaludercic <philipk@posteo.net>,  hi@ypei.me,  emacs-devel@gnu.org
> Date: Sat, 28 Aug 2021 17:03:10 +0200
> 
> What I was thinking of is that some of prog modes that ship with Emacs are
> frankly not very good compared to external packages, and people are anyway
> downloading something else (for exapel js vs js2 or lisp vs slime/sly). It would
> be nice if everything was in Emacs by default but, maybe it is better to lessen
> the burden on Emacs devs themselves and point users to external package instead.

Lessening the maintenance burden is not the most important goal of
Emacs development; providing users with better support for their
editing jobs is more important.

I don't think anyone will disagree that Emacs should support JS OOTB.

> Now that we have non gnu elpa, and Stefan says it is no problem to ship someone
> elses packages, maybe some good soul could package those into non gnu elpa and
> Emacs could do like some other text editors, simply point users to download
> needed package or download it on demand?
> 
> There was no non gnu elpa before, maybe you could revise the policy in that
> light?

Non-GNU ELPA is not part of the equation, because packages put there
will probably never be able to become part of Emacs.  The issue at
hand here is whether to have packages that support important features
in GNU ELPA or in core.

Re: Adding major or popular language modes to Emacs distribution

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: hi@ypei.me,  emacs-devel@gnu.org
>> Date: Sat, 28 Aug 2021 14:30:16 +0000
>> 
>> > We should definitely make the PL modes more consistent wrt the basic
>> > key bindings.  But having sch packages in ELPA doesn't help solving
>> > this problem, because it's an orthogonal issue, right?
>> 
>> Yes, I was jut mentioning that if there ever were a push to include more
>> major modes in Emacs, that something like this might be worth
>> considering.
>
> To clarify, I was only talking about programming languages that are
> very popular -- I think Emacs should offer those OOTB.  I didn't mean
> we should necessarily have in core every possible language under the
> sun.  We could discuss the less popular ones on a case by case basis.

Out of curiosity, I checked [0] to see what the languages are said to be
popular:

| Language             | Status                                |
|----------------------+---------------------------------------|
| C                    | Built-In                              |
| Python               | Built-In                              |
| Java                 | Built-In                              |
| C++                  | Built-In                              |
| C#                   | ELPA                                  |
| Visual Basic         | Not packaged, just EmacsWiki[1]       |
| JavaScript           | Built-In and ELPA (js2-mode)          |
| PHP                  | MELPA, NonGNU proposed                |
| Assembly             | Built-In                              |
| SQL                  | Built-In                              |
| Groovy               | MELPA                                 |
| Classical VB         | Couldn't find anything                |
| Fortran              | Built-In                              |
| R                    | MELPA (via ess)                       |
| Ruby                 | Built-In                              |
| Swift                | MELPA, NonGNU proposed                |
| MATLAB               | MELPA                                 |
| Go                   | NonGNU                                |
| Prolog               | Built-In                              |
| Perl                 | Built-In                              |
| SAS                  | MELPA (via ess)                       |
| Delphi/Object Pascal | Just GitHub[2]                        |
| Objective C          | Built-In                              |
| Rust                 | NonGNU                                |
| Scratch              | Not applicable (graphical)            |
| Julia                | MELPA, NonGNU proposed                |
| Ada                  | Built-In and ELPA                     |
| Lisp                 | Built-In                              |
| Dart                 | MELPA, NonGNU proposed                |
| PL/SQL               | Built-In (part of sql-mode)           |
| (Visual) FoxPro      | Nothing I could find                  |
| Scala                | MELPA, NonGNU Proposed                |
| ABAP                 | Just GitHub[3]                        |
| COBOL                | ELPA                                  |
| Logo                 | Mentioned on EmacsWiki[4]             |
| F#                   | MELPA                                 |
| Kotlin               | MELPA, NonGNU proposed                |
| Transact-SQL         | Unsure if this is part of sql-mode    |
| Lua                  | NonGNU                                |
| Ladder Logic         | Nothing or not applicable (graphical) |
| VBScript             | Unsure how VBScript relates to VB     |
| D                    | MELPA, NonGNU proposed                |
| Clojure              | NonGNU                                |
| LabVIEW              | Not applicable (graphical)            |
| Nim                  | MELPA, NonGNU proposed                |
| VHDL                 | Built-In                              |
| Apex                 | GitHub[5]                             |
| TypeScript           | MELPA, NonGNU proposed                |
| Bash                 | Built-In                              |

There are more, but I am not sure how productive it is to continue. What
I probably missing more urgently is full compatibility, especially with
complex languages like C++, or languages embedded in one another as web
developers often work with.

[0] https://www.tiobe.com/tiobe-index/
[1] https://www.emacswiki.org/emacs/VisualBasicMode
[2] https://github.com/ki11men0w/emacs-delphi-mode
[3] https://github.com/hugo-dc/abap-mode
[4] https://www.emacswiki.org/emacs/LogoMode
[5] https://github.com/ctomo/apex-mode

-- 
	Philip Kaludercic

Re: Adding major or popular language modes to Emacs distribution

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> Out of curiosity, I checked [0] to see what the languages are said to be
> popular:

Thanks -- interesting list.

> | Language             | Status                                |
> |----------------------+---------------------------------------|
> | C                    | Built-In                              |
> | Python               | Built-In                              |
> | Java                 | Built-In                              |
> | C++                  | Built-In                              |
> | C#                   | ELPA                                  |

To clarify -- when I said that C# didn't need to be in Emacs Core, it's
not because it's not a major language (it is), but it's my opinion that
it's unlikely that a large number of people would want to use Emacs when
programming in C#.  (Because the IDEs that come bundled with the popular
C# compilers are what people are using, and it seems unlikely that many
people would want to switch away from those.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Adding major or popular language modes to Emacs distribution

[Theodor Thornhill]

On 28 August 2021 17:53:51 CEST, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Philip Kaludercic <philipk@posteo.net> writes:
>
>> Out of curiosity, I checked [0] to see what the languages are said to be
>> popular:
>
>Thanks -- interesting list.
>
>> | Language             | Status                                |
>> |----------------------+---------------------------------------|
>> | C                    | Built-In                              |
>> | Python               | Built-In                              |
>> | Java                 | Built-In                              |
>> | C++                  | Built-In                              |
>> | C#                   | ELPA                                  |
>
>To clarify -- when I said that C# didn't need to be in Emacs Core, it's
>not because it's not a major language (it is), but it's my opinion that
>it's unlikely that a large number of people would want to use Emacs when
>programming in C#.  (Because the IDEs that come bundled with the popular
>C# compilers are what people are using, and it seems unlikely that many
>people would want to switch away from those.)
>

What? There's at least two of us!

Joking aside, I didn't mean to start a "why isn't my mode in core" thread. The rules just seemed a little arbitrary. Also now with LSP a thing this is more viable than ever. The only benefit would be one off edits wouldn't need a package download.

Not a major issue though

Re: Adding major or popular language modes to Emacs distribution

[Arthur Miller]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Out of curiosity, I checked [0] to see what the languages are said to be
>> popular:
>
> Thanks -- interesting list.
>
>> | Language             | Status                                |
>> |----------------------+---------------------------------------|
>> | C                    | Built-In                              |
>> | Python               | Built-In                              |
>> | Java                 | Built-In                              |
>> | C++                  | Built-In                              |
>> | C#                   | ELPA                                  |
>
> To clarify -- when I said that C# didn't need to be in Emacs Core, it's
> not because it's not a major language (it is), but it's my opinion that
> it's unlikely that a large number of people would want to use Emacs when
> programming in C#.  (Because the IDEs that come bundled with the popular
> C# compilers are what people are using, and it seems unlikely that many
> people would want to switch away from those.)

How popular is .net core on gnu/linux? Do peole write lots of C# stuff for that
runtime in gnu/linux environment?

I am sure though that Lars resoning there holds for VB/VBA/VBScript.

Re: Adding major or popular language modes to Emacs distribution

[Theodor Thornhill]

On 28 August 2021 18:55:00 CEST, Arthur Miller <arthur.miller@live.com> wrote:
>Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Out of curiosity, I checked [0] to see what the languages are said to be
>>> popular:
>>
>> Thanks -- interesting list.
>>
>>> | Language             | Status                                |
>>> |----------------------+---------------------------------------|
>>> | C                    | Built-In                              |
>>> | Python               | Built-In                              |
>>> | Java                 | Built-In                              |
>>> | C++                  | Built-In                              |
>>> | C#                   | ELPA                                  |
>>
>> To clarify -- when I said that C# didn't need to be in Emacs Core, it's
>> not because it's not a major language (it is), but it's my opinion that
>> it's unlikely that a large number of people would want to use Emacs when
>> programming in C#.  (Because the IDEs that come bundled with the popular
>> C# compilers are what people are using, and it seems unlikely that many
>> people would want to switch away from those.)
>
>How popular is .net core on gnu/linux? Do peole write lots of C# stuff for that
>runtime in gnu/linux environment?
>

They do, yes! How many? No idea. But it seems semiregular in Norway at least, were Linux finally takes over the server domain.

>I am sure though that Lars resoning there holds for VB/VBA/VBScript.
>

Probably

Re: Adding major or popular language modes to Emacs distribution

[Dmitry Gutov]

On 28.08.2021 19:28, Theodor Thornhill wrote:
> Joking aside, I didn't mean to start a "why isn't my mode in core" thread. The rules just seemed a little arbitrary. Also now with LSP a thing this is more viable than ever. The only benefit would be one off edits wouldn't need a package download.

Good point about LSP, but since it needs an installation from (M)ELPA 
anyway, the only benefit is for one-off edits that somehow don't use the 
main user's setup. Which would seem to be a rare thing to do.

Re: Adding major or popular language modes to Emacs distribution

[Ergus]

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

Actually, it is more scalable and optimal to invest time implementing  lsp and tree-sitteer building support because  supporting more external packages and modes one by one for languages that maybe won't be popular after some years, so they will become unmaintained and unremovable from vanilla. Most of the code in the programming modes (and performance penalty)  is actually dedicated to syntax highlight, indentation, and code navigation. Something that tree-sitee will do better and faster in most cases. Then language specific modes could add just some extra specific details... And we can invest then our time improving, not implementing basic support.
Some external packages are also very limited and there are other external additions and plugins to make them functional... So adding more and more modes for languages is worthless. Use a ring to rule them all please.

On August 28, 2021 10:40:07 PM GMT+02:00, Dmitry Gutov <dgutov@yandex.ru> wrote:
>On 28.08.2021 19:28, Theodor Thornhill wrote:
>> Joking aside, I didn't mean to start a "why isn't my mode in core" thread. The rules just seemed a little arbitrary. Also now with LSP a thing this is more viable than ever. The only benefit would be one off edits wouldn't need a package download.
>
>Good point about LSP, but since it needs an installation from (M)ELPA 
>anyway, the only benefit is for one-off edits that somehow don't use the 
>main user's setup. Which would seem to be a rare thing to do.
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii]

> Date: Sun, 29 Aug 2021 04:15:05 +0200
> From: Ergus <spacibba@aol.com>
> CC: Eli Zaretskii <eliz@gnu.org>, hi@ypei.me
> 
> Actually, it is more scalable and optimal to invest time implementing lsp and tree-sitteer building support
> because supporting more external packages and modes one by one for languages that maybe won't be
> popular after some years, so they will become unmaintained and unremovable from vanilla. Most of the code
> in the programming modes (and performance penalty) is actually dedicated to syntax highlight, indentation,
> and code navigation. Something that tree-sitee will do better and faster in most cases. Then language
> specific modes could add just some extra specific details... And we can invest then our time improving, not
> implementing basic support.
> Some external packages are also very limited and there are other external additions and plugins to make
> them functional... So adding more and more modes for languages is worthless. Use a ring to rule them all
> please.

We do have a process of obsoleting unused packages, so modes that
become unused and unmaintained have a clear path there.

Also, please don't assume that LSP and Tree Sitter will be here
forever.  They can also fall out of fashion and die, at which point it
would be good for us to have some fallbacks.

Last, but not least: support for a programming language isn't limited
to what LSP, TS, and their ilk provide, it includes additional
features that are specific to Emacs.  Two trivial ones:
auto-mode-alist and menu-bar items for the language.  Less trivial
ones could include REPL-style invocation, support for language
interpreter, etc.