But what's ERT?

Some ideas:

• last time I looked it had about 9000 lines, so my first approach works be to divide and conquer into smaller modules.
• some Elisp code should be generated from Perl. (Lispers will kill me) For instance a large chunk is made of help docs dating back from Perl 4
• Ilya always wanted to be backwards compatible with emacs 18 or 19 which didn't have a very fancy parsing tech. Consider dropping that Code.
• you'll need a test suite, preferably written in Perl too.

Thanks for the feedback! To wit: ERT is Emacs Lisp Regression Testing.
• Dividing the existing source is surely an option, but isn't very high on my priority list. There's little benefit, and a division needs care for production and installation to fit into the Emacs package. Emacs makes navigation in a big file rather easy. New features, in particular optional stuff, might go into extra files.
• Updating the docs is ... indeed interesting. There used to be a tool (written in Perl) to convert POD to texinfo, to read it directly in Emacs, but this seems to be no longer functional.
• I've already dropped all the special cases for XEmacs, Emacs below version 26, font-lock-extra, choose-color.el, and cperl-mode's homegrown fontification for multiline strings. Did I miss something? Apropos: The selection of the minimum Emacs version is a somewhat unfortunate consequence from cperl-mode being bundled with Emacs. I haven't checked yet how much effort a backport to, say, Emacs 24 would be.
• Yes, I need a test suite, and I've started writing tests for the bugs I fixed. However, I doubt that I'll write tests for the existing code unless I find bug reports. Though I would love to write a test suite in Perl (the Test:: infrastructure is lightyears ahead of ERT), ERT is mandated if you want to get stuff into Emacs. Also, it isn't that easy to query the fontification of a particular character in an Emacs buffer from Perl...

With regard to integrating with Perl, a connection to modules like PPI or even Code::ART would be interesting. To quote THeDamian: How hard can that be? But then, I'm not Damian, he's doing his sourcery in Vimscript, so don't hold your breath.

> it isn't that easy to query the fontification of a particular character in an Emacs buffer from Perl

Just use htmlize and your favourite Perl HTML parser ;-)

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Hi
• division: the final .el should be a single one, sure. I was thinking of a build and testing process triggered from a Perl script joining different parts. Testing with different emacs versions° is not easy and you'll find more contributors providing Perl tests.
• docs: sorry, you misunderstood me, cperl has a long list of one liner description for each Perl command. IMHO these should be outsourced.
• info: What you mean is the hypertext help system which relies on static perldocs in "info" format. Info is great for navigation of deep manuals, perldocs are rather flat and should be IMHO better displayed with "woman.el" (man doesn't work on windows).
• if you drop support for older or other versions like XEmacs you should maybe consider renaming the fork of cperl-mode

On a different note: elisp regexing is a PITA because of slasheritis and pretty unreadable. (Btw: XEmacs solved this with raw strings)

I was thinking of translating Perl regex to lisp to open up for a broader audience.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

°) and Perl versions and extensions

Very good!

I have in most of my Perl files:

# (compile (concat "perltidy " (buffer-name)) nil)
# (ediff-files (concat (buffer-name) ".tdy") (buffer-name))
[download]

A command in the modernized cperl-mode to run perltidy with the input from a emacs buffer hade been good!?

So something like perltidy-mode?

Or rather, run perltidy with input from a buffer which has not yet been saved, and write the output to another buffer? I guess that makes sense (probably also for perlcritic). Please open an issue at my Github Repo!