On Oct 3, 2006, at 2:49 AM, Chris Dolan wrote:
On Oct 3, 2006, at 1:29 AM, Paul Cochrane wrote:
Hi all,
In the process of trying to finish off the perl coda cage task, I
notice that the Perl::Critic policy for the emacs/vim coda skips
__END__ and __DATA__ sections at the end of perl files, however
vim (I
don't know about emacs) requires the coda to be within either the
first or last 5 lines of the file (by default) for which the editor
settings are to be applied, and so if one has a large __END__ or
__DATA__ section (not exactly difficult) the coda will be missed by
vim.
A lot of the time __END__ sections are used for pod, so there is an
easy fix for these situations such that the coda can be added without
affecting perldoc output namely: put a C<=cut> at the end of the pod,
before the coda. However, this doesn't work in all situations, and I
believe the coda will add itself to the data in the __DATA__
block, am
I correct?
In short, the coda needs to be at the end of each of the files,
however, not to be included in any present __END__ or __DATA__
blocks;
how do we get around this in nice, general way?
Thanks heaps in advance,
Paul
Paul,
Good point, I meant to bring this up myself when I was fiddling
with lib/Perl/Critic/Policy/CodeLayout/UseParrotCoda.pm
I agree that using =cut in __END__ is the right solution. I have
no idea how to handle __DATA__ since you can't put an __END__
embedded in a __DATA__ section.
If Will Coleda (or someone else) approves the coda-after-__END__
spec change, I'll be happy to code that up in
CodeLayout::UseParrotCoda.
Chris
Yes please. The PDD already says "end with this code", and I was
simply doing a first pass implementation. We should also, if the
__DATA__ problem is described accurately here, amend the PDD to say
that it's ok to begin with (post shebang & copyright, I suppose), if
the particular file requires it.
Go ahead and code this against your updated version, I'll get that
applied shortly.
Thanks, guys.
--
Will "Coke" Coleda
[EMAIL PROTECTED]
