Bring new language features and popular DSLs into cperl-mode
cperl-mode, created by Bob Olson and then enhanced and made popular by Ilya Zakharevich in the previous century, is the most popular major mode for editing Perl code with Gnu Emacs. A version of cperl-mode is included with Emacs. However, recent and upcoming enhancements of Perl are not (yet) included.
The starting point for this repository is cperl-mode.el from the Gnu Git repository as of 2020-06-04, which includes Jonathan Rockway's additions.
If you have found a bug or desire a change in cperl-mode, then we
recommend the traditional M-x report-emacs-bug
procedure, make sure
to mention "cperl-mode" in the email subject. It simply gets more
attention over there (including mine).
Issue reports or discussion here isn't lost, either. If you send pull requests, please note that substantial contributions can only be included with Emacs if the authors transfer the copyright to the Free Software Foundation.
CPerl mode is not (yet) available as an installable package. A manual installation isn't that difficult, though: It consists of just one file, cperl-mode.el, and it can be used as a drop-in replacement for the cperl-mode.el which ships with Emacs.
So, to use this version of cperl-mode.el, either clone this repository or just copy cperl-mode.el to a location of your choice, and then tell Emacs where to find it in your init file:
(add-to-list 'load-path "/your/directory/here")
Alternatively, you could use the "current" version from the Emacs source tree. cperl-mode.el from the master branch works with Emacs 26.1 or newer. This version (occasionally mirrored to the upstream branch in this repository) does not contain the experimental support for language extensions, but even more bug fixes.
The Perl programming language is evolving, and so should cperl-mode. Currently there's Ovid's initiative to bring "native" object-oriented keywords into the Perl core. We can't run this code yet, but why shouldn't we be able to write it with proper support by the editor?
Also, many popular modules import subroutines into your source code which behave like keywords, though technically they are just plain subroutines. Yet, I'd love to read such source code with highlighting of these keywords. Examples for such modules are OO-frameworks like Moose et al. with "keywords" like has
and extends
, test frameworks with is
, is_deeply
and many others, Plack with builder
, enable
and mount
, and various exception handlers with try
, catch
, and finally
(the latter are already included in vanilla cperl-mode thanks to Jonathan Rockway).
During the migration period to the Emacs repository we have three branches here, but the number will decrease in due time.
cperl-mode.el
from the master
branch of the official repository of Gnu
Emacs. It contains
about a dozen bug fixes which have not yet been distributed with
Emacs. This version now covers Perl syntax up to version 5.38
(in particular, the feature 'class' stuff).My first (unpublished) approach was a mode derived from cperl-mode, but this ran into too many issues with the current code of cperl-mode, so I decided to dig deeper and start refactoring. I plan to:
regexp-opt
at runtime to make them easier to read (this is a FIXME anyway)As an effect, I expect this version to be slower than the original, but I don't think this is an issue in 2020. Also, I expect to make slow progress, as I'm doing this in my spare time.
The current status is reported in the NEWS file, which follows Emacs conventions for style and location.
Once the features in the master branch are considered sufficiently stable, it is intended to distribute it using the usual Emacs channels: One option is to make it the official version which ships with Emacs. In that case, publishing it via ELPA makes sense, to allow adjustments to new versions of Perl or new features on our own schedule. Most likely a dual life of CPerl mode as a core part of Emacs and an ELPA package will be the way to go.
This repository might continue to exist for experimental stuff or for collecting feedback from the Perl community: The Emacs mailing lists might have much "noise" which isn't relevant for Perl programmers at all.