I've been tying Emacs tighter and tighter to Perl::Critic and B::Lint. I switched off of B::Lint for awhile because I was doing Perl::Critic and I noticed that my error rate went through the roof. Perl::Critic doesn't prevent me from writing invalid perl. I'm going to have to insist on integrating Lint with P::C or at least P::C plus a syntax check. that is, a *real* compile. This "we don't invoke perl for safety" stuff has got to go. Blech. It prevents important checks from occuring.
Emacs minor mode's I've written or just been hacking on: perl-syntax-mode, perl-lint-mode, perltidy-mode, perlcritic-mode.
I figure I'd like to implement some better autocompletion once these basic tools all work together. I'm kind of surprised no one did the work to integrate all this stuff before. IDEs rock, right? Right?
I saw a talk given by Joe Brenner on his Emacs extension Perlnow. I've been playing with it off and on but I have been in vim land mostly as of late, but it has most of what you need for an Emacs Perl IDE. Only thing I was missing there was PerlTidy and Critic.
This "we don't invoke perl for safety" stuff has got to go. Blech. It prevents important checks from occuring.
Re:Compile safety
jjore on 2006-07-25T20:50:47
I am trying to haveuse stricter;. I happen to be doing this in my editor while I'm writing the code instead of the code's compile or runtime.
In practice I've noticed it isn't difficult to just have Emacs chain multiple checks so I guess I care much less now.Re:Compile safety
ChrisDolan on 2006-07-28T05:01:22
Cool, that's interesting. I've been meaning to ask you for a long time: is it easy to override the save-time checks if, say, you're trying to run to catch a bus?
Re:Compile safety
jjore on 2006-07-28T06:33:00
Sure. You just turn off the appropriate minor mode. For perlcritic-mode, you're already in perlcritic-mode so you run `M-x perlcritic-mode' to turn it off. The safeties are now off so you're free to write whatever you want without hearing about it from Perl::Critic or whatever.
I'm going to have to insist on integrating Lint with P::C or at least P::C plus a syntax check.
P::C is not the place for those. If you do it, keep it to yourself please. P::C is for best practices and not to see if something is syntactically correct.
Re:No no no
jjore on 2006-07-25T20:54:09
Well no. P::C and all your local plugins are where you put all of your static analysis stuff with the intention of finding bad or dodgy stuff.
There's one part of P::C which is specifically focused on Damian's PBP book but that's not P::C's entire universe. In fact, now that I've thought of it, there's nothing preventing there just being a plugin that does a real syntax check.
It doesn't even have to live in the P::C dist since CPAN will accomodate all comers.
Re:Well..
jjore on 2006-07-25T21:10:46
That's spiffy but most people aren't editing unsafe code. I'm not. I don't think I am anyway. My perception of my risk profile is that I'm not going to be editing files that have BEGIN { system "bad stuff" } in it. I could be wrong.
I do know that syntax checking while I'm writing is a boon. I also know there are some checks for "bad stuff" that I can't do in P::C because I don't haven't resolved what happened after a use Foo::Bar; that imported some useful function like any(&@) but it had a signature which changed how perl parses.
The overall idea is that I want to get more gentle nudges about bad style, typos and thinkos before I ever switch away from my editor. I want this simple stuff to be easier so I can ignore it more and concentrate just on the harder stuff that can't be machine analyzed.
