emacs-devel
[Top][All Lists]
Advanced

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

Re-vitalizing cperl-mode


From: Harald Jörg
Subject: Re-vitalizing cperl-mode
Date: Thu, 2 Jul 2020 13:34:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0

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



reply via email to

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