|
in reply to Breathing life into the (Emacs) cperl-mode
Great project.
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.
and... TL;dW ;)
|
Re^2: Breathing life into the (Emacs) cperl-mode
by haj (Vicar) on Jul 02, 2020 at 16:28 UTC
|
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.
| [reply] |
|
|
| [reply]
[d/l] |
|
|
$a++ <span class="constant">/</span>
<span class="string"> </span>
<span class="variable-name">$b</span>
<span class="string">; # </span>
<span class="constant">/</span>;
That surely is a lot of noise. As you can see (you can, can't you?), this is the output from a broken cperl-mode.
My preferred approach for large-scale fontification tests would be Lindydancer's faceup markup, which together with the other repositories by the same author are really awesome tools to debug and test font-lock features.
Advertisement: As a recent addition, I added Damian Conway's "Perl Best Practice" recommendations for indenting code to M-x cperl-indent-style. I guess that amongst Perlers PBP is waaay more popular than K&R, BSD, or GNU conventions. | [reply]
[d/l] |
|
|
|
|
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.
°) and Perl versions and extensions
| [reply] |
|
|
About Perl documentation...
...perldocs are rather flat and should be IMHO better displayed with "woman.el" (man doesn't work on windows).
Update: I've just pushed a cperl-mode where M-x cperl-perldoc just works on Windows. I didn't find woman.el particularly rewarding, though, and I took a different route. On the plus side, hyperlinks in POD files now work, and are resolved in your local installation (unless they are https links). Many perldoc pages are flat, but others like the Moose::Cookbook make more fun when links work.
Other documentation functions of cperl-mode will also be made available on Windows, as my time permits.
The code is at cperl-mode.el on GitHub, there's also a List of changes.
I've also completed the FSF paperwork, so there are chances that some changes will make their way into the official Emacs distribution.
| [reply] |
|
|
| [reply] |
|
|
|
|
Another update:
perldocs are rather flat and should be IMHO better displayed with "woman.el" (man doesn't work on windows).
As it turns out, this is already available. Not from Emacs nor ELPA/MELPA, but there's Emacs::PDE on CPAN. This distribution provides, among other tools, M-x perldoc which is using WoMan and works quite fine on Windows. Even better, there's a command M-x perldoc-tree which offers all local docs in a nice tree view.
This, of course, makes a refurbishment of the perldoc stuff in cperl-mode a lot less interesting.
| [reply] |
|
|
|
|
|
|
|
