Re: Adding major or popular language modes to Emacs distribution

[Eli Zaretskii <eliz@gnu.org>]

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