Re-vitalizing cperl-mode

Re-vitalizing cperl-mode

[Harald Jörg]

Hello Emacs devs,

Emacs comes with cperl-mode, a major mode to edit Perl programs.
I am using it, and I'm happy with it.

However, Perl is evolving... and I noticed that cperl-mode isn't
developed accordingly.  New versions of Perl might come with new
keywords for syntax highlighting (e.g. "isa" in Perl 5.32), or with
new syntactic constructs which affect highlighting, indenting, and
indexing for imenu (e.g. "package Foo { ...; }" in Perl 5.14).
These are not handled correctly by cperl-mode right now.

I come here to ask for guidance how to proceed and to offer help.

For the easy part, I created my own repository for cperl-mode at
https://github.com/HaraldJoerg/cperl-mode. While working on that, I
found that some things are easy to fix, while others need some
refactoring, so things have diverged a bit, but not too much.  I
maintain the current state of my hacking at
https://github.com/HaraldJoerg/cperl-mode/blob/master/etc/NEWS.

So I could file bug reports and pull requests against Emacs which
would be trivial in some cases... but some come with bigger changes in
the innards of cperl-mode.  There is no test suite for cperl-mode, and
my very limited experience with elisp doesn't help.

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?

Would it be an option to give cperl-mode a "dual life" in Emacs and in
(M)ELPA?  That way, changes in the Perl programming language could be
reacted upon without waiting for the next release of Emacs - and new
features could be tested by volunteers from the Perl community before
they are, eventually, merged into Emacs when they are considered
stable.

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

In any case, I'll also ask for feedback in the Perl community.  First
casual contacts in Perl's IRC channel stirred interest, and there seem
to be as many opinions as participants.  Business as usual :)
--
Cheers, and thanks for providing Emacs and cperl-mode,
haj

Re: Re-vitalizing cperl-mode

[Eli Zaretskii]

> From: Harald Jörg <haj@posteo.de>
> Date: Thu, 2 Jul 2020 13:34:43 +0200
> 
> I come here to ask for guidance how to proceed and to offer help.
> 
> For the easy part, I created my own repository for cperl-mode at
> https://github.com/HaraldJoerg/cperl-mode. While working on that, I
> found that some things are easy to fix, while others need some
> refactoring, so things have diverged a bit, but not too much.  I
> maintain the current state of my hacking at
> https://github.com/HaraldJoerg/cperl-mode/blob/master/etc/NEWS.

Thank you for your interest in Emacs.

If you'd like to contribute these changes to the Emacs project, I
suggest to do 2 things in parallel:

  . use "M-x report-emacs-bug RET" to file a series of bug reports for
    the individual problems and/or improvements you'd like to submit,
    describing the issues and attaching the relevant patches

  . start the legal paperwork of assigning copyright for your changes
    to the FSF, which is needed for substantial contributions (I can
    send you the form to fill if you agree)

Then we can take this from there.

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

We don't maintain MELPA.  As for ELPA, sure, it's possible to have a
package in both places.

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

See CONTRIBUTE for Emacs; see README in the GNU ELPA repository for
the ELPA requirements.

Re: Re-vitalizing cperl-mode

[Harald Jörg]

Hello Eli,


>> From: Harald Jörg <haj@posteo.de>
>> Date: Thu, 2 Jul 2020 13:34:43 +0200
>>
>> I come here to ask for guidance how to proceed and to offer help.
>>
>> For the easy part, I created my own repository for cperl-mode at
>> https://github.com/HaraldJoerg/cperl-mode. While working on that, I
>> found that some things are easy to fix, while others need some
>> refactoring, so things have diverged a bit, but not too much.  I
>> maintain the current state of my hacking at
>> https://github.com/HaraldJoerg/cperl-mode/blob/master/etc/NEWS.
> 
> Thank you for your interest in Emacs.
> 
> If you'd like to contribute these changes to the Emacs project, I
> suggest to do 2 things in parallel:
> 
>   . use "M-x report-emacs-bug RET" to file a series of bug reports for
>     the individual problems and/or improvements you'd like to submit,
>     describing the issues and attaching the relevant patches

Ok, I'll do that.

I don't have patches for all the problems, though, and some of the
problems can't be targeted in isolation.

>   . start the legal paperwork of assigning copyright for your changes
>     to the FSF, which is needed for substantial contributions (I can
>     send you the form to fill if you agree)

Thanks!  Of course I agree, but Stefan already sent the form, it is on
its way back.

> Then we can take this from there.
> 
>> Would it be an option to give cperl-mode a "dual life" in Emacs and in
>> (M)ELPA?
> 
> We don't maintain MELPA.  As for ELPA, sure, it's possible to have a
> package in both places.
> 
>> In any case: What rules / conventions / tools and frameworks should I
>> obey to make my changes palatable for Emacs and/or (M)ELPA?
> 
> See CONTRIBUTE for Emacs; see README in the GNU ELPA repository for
> the ELPA requirements.

Thanks for the pointers!
-- 
Cheers,
haj

Re: Re-vitalizing cperl-mode

[Stefan Monnier]

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?

Re: Re-vitalizing cperl-mode

[Harald Jörg]

Hello Stefan,

>> Emacs comes with cperl-mode, a major mode to edit Perl programs.
> 
> As well as `perl-mode`, indeed.

I know, but as far as I recall I've never used perl-mode.

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

Oh, they do get love.  From their users.  Their code doesn't, though :)

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

That might be an option, yes.

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

This is highly appreciated!

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

Indeed, limited... It also seems to exercise some interesting border
cases of fontification.  But manual tests are not very pleasant.

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

Thanks!

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

Yes, I am aware.  It seems that Emacs incorporated changes from this
repo, but the cleanups done in the Emacs version weren't merged back.

In short: Jonathan Rockway added stuff for Perl 5.10 and two modules
which bring their own keywords.  I want to go up to 5.32 and beyond,
and have a mechanism to support _any_ module which adds their own
keywords.

-- 
Cheers,
haj