[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding major or popular language modes to Emacs distribution

From: Philip Kaludercic
Subject: Re: Adding major or popular language modes to Emacs distribution
Date: Sat, 28 Aug 2021 13:45:41 +0000

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

reply via email to

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