emacs-devel
[Top][All Lists]
Advanced

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

Re: Re-vitalizing cperl-mode


From: Stefan Monnier
Subject: Re: Re-vitalizing cperl-mode
Date: Thu, 02 Jul 2020 09:40:14 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Hi,

> Emacs comes with cperl-mode, a major mode to edit Perl programs.

As well as `perl-mode`, indeed.

> However, Perl is evolving... and I noticed that cperl-mode isn't
> developed accordingly.

Indeed, neither `perl-mode` nor `cperl-mode` are getting much love
these days.

> Should I just keep the status quo - and the Emacs dev team will decide
> whether, and which of my changes you will adopt into the next Emacs
> release?

Much better would be for you to step up as maintainer of the package:
it's likely that in many cases the "Emacs dev team" wouldn't really have
the resources or expertise to judge such changes.

We can give guidance and feedback on the quality of the Elisp code, of
course.

> Would it be an option to give cperl-mode a "dual life" in Emacs and in
> (M)ELPA?

Yes, we could easily distribute emacs.git's ` cperl-mode.el` as a GNU
ELPA package as well (like we already do for python.el and a bunch of
others).

> In any case: What rules / conventions / tools and frameworks should I
> obey to make my changes palatable for Emacs and/or (M)ELPA?

Since `cperl-mode.el` is distributed with Emacs, its better to try and
obey the conventions used for Emacs's own Elisp code.

Adding test cases under emacs.git/test would be a great contribution
as well (there's currently a very limited set of testcases in
test/manual/indent/perl.perl).

The main rule there is that code's copyright needs to be assigned to
the FSF.  I'll contact you off-list for that.


        Stefan


PS: BTW, I assume you're familiar with https://github.com/jrockway/cperl-mode?




reply via email to

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