On Tue Dec 19 16:30:34 2006, [EMAIL PROTECTED] wrote:
> Nicholas Clark wrote:
> >
> > To seek clarification - having those as global settings for cperl
isn't
> > likely to be an issue? Or having them in editor blocks?
>
> I meant globally.
>
> It's really not a big deal, though. For the immedia
On Tue, Dec 19, 2006 at 04:30:08PM -0800, Allison Randal wrote:
> Nicholas Clark wrote:
> >
> >To seek clarification - having those as global settings for cperl isn't
> >likely to be an issue? Or having them in editor blocks?
>
> I meant globally.
Ah. There have been times when it would have been
It's really not a big deal, though. For the immediate problem, let's
just make an exception and leave the hints out of Perl files with
__END__ or __DATA__ blocks.
Sounds good. I can update the Perl::Critic policy, and make a note in pdd07.
Mark it as a cage cleaner task for some point down the
All it does is turn on cperl mode for emacs, and set tabs to 4 spaces
for vim and emacs. Not likely to significantly interfere with any
repository you work on. (I actually gave up on the tab key in vim years
ago. I type literal spaces, and my brain automatically adjusts my
indenting to the surroun
Nicholas Clark wrote:
To seek clarification - having those as global settings for cperl isn't
likely to be an issue? Or having them in editor blocks?
I meant globally.
It's really not a big deal, though. For the immediate problem, let's
just make an exception and leave the hints out of Perl
On Tue, Dec 19, 2006 at 01:08:14PM -0800, Allison Randal wrote:
> Nicholas Clark wrote:
> >On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote:
> >
> >>to every source file, and a maintenance burden. Both vim and emacs allow
> >>top-level settings of these preferences, which is a more a
Nicholas Clark wrote:
On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote:
to every source file, and a maintenance burden. Both vim and emacs allow
top-level settings of these preferences, which is a more appropriate
place for them.
This assumes that all the projects you use the e
On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote:
> to every source file, and a maintenance burden. Both vim and emacs allow
> top-level settings of these preferences, which is a more appropriate
> place for them.
This assumes that all the projects you use the editor for have the
On Tuesday 19 December 2006 10:05, Allison Randal wrote:
> The editor hints aren't actually very helpful, but they do add clutter
> to every source file, and a maintenance burden. Both vim and emacs allow
> top-level settings of these preferences, which is a more appropriate
> place for them.
I a
Paul Cochrane wrote:
Having editor hints in the source can have value as it can reduce the
cage cleaning load by getting the editor to indent people's code
consistently (admittedly this only helps people who use emacs and vim
in this case) so in that sense it is worthwhile having them around.
The
Having editor hints in the source can have value as it can reduce the
cage cleaning load by getting the editor to indent people's code
consistently (admittedly this only helps people who use emacs and vim
in this case) so in that sense it is worthwhile having them around.
The coda is added to all
On Tue, Dec 19, 2006 at 05:20:06PM +0800, Lee Duhem wrote:
> Allison wrote:
> >My vote is on removing all emacs and vim settings from our source code
> >files.
> and so you can get really bad code appearance.
I'm curious, why is that? We're already discouraging (if not
disallowing) hard tabs in t
My vote is on removing all emacs and vim settings from our source code
files.
and so you can get really bad code appearance.
Paul Cochrane wrote:
The problem that I'm trying to solve
here is: how do we add the settings information to perl language files
such that it doesn't cause problems with __END__ and __DATA__ blocks,
is testable by perlcritic, emacs *and* vim pick up their settings
values, and it doesn't interfer
On Dec 18, 2006, at 1:57 AM, Paul Cochrane wrote:
Be aware that you cannot use the verbose form of Emacs settings at
the beginning of a file, unless the file is shorter than 3000 bytes.
See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy
for more details:
So this means we need t
Be aware that you cannot use the verbose form of Emacs settings at
the beginning of a file, unless the file is shorter than 3000 bytes.
See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy
for more details:
So this means we need to put the emacs and vim settings at the end of
the f
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Sun, 17 Dec 2006 15:03:10 -0500
From: Chris Dolan <[EMAIL PROTECTED]>
Date: Sun, 17 Dec 2006 13:22:53 -0600
. . .
Be aware that you cannot use the verbose form of Emacs settings at
the beginning of a file, unless th
From: Chris Dolan <[EMAIL PROTECTED]>
Date: Sun, 17 Dec 2006 13:22:53 -0600
On Dec 16, 2006, at 12:41 PM, Paul Cochrane via RT wrote:
> Hi all,
>
> We could close this ticket if a decision were made as to whether or
> not
> the emacs/vim formatting information can be put
On Dec 16, 2006, at 12:41 PM, Paul Cochrane via RT wrote:
Hi all,
We could close this ticket if a decision were made as to whether or
not
the emacs/vim formatting information can be put at the *beginning*
of a
file in the case where __END__ or __DATA__ blocks are used within a
perl source
Hi all,
We could close this ticket if a decision were made as to whether or not
the emacs/vim formatting information can be put at the *beginning* of a
file in the case where __END__ or __DATA__ blocks are used within a
perl source file.
What are people's opinions? Would it be too ugly to p
Hi all,
The attached patch to the coding standards pdd concerns how we handle
the parrot emacs/vim coda in perl source files when the files contain
__END__ or __DATA__ blocks. The reason for the patch is that vim looks
at only the first or last five lines of a file to see if there is any
styl
Hi,
This patch changes the semantics of the checking for the Perl code
coda in Perl::Critic::Policy::CodeLayout::UseParrotCoda. At present
the Perl code coda is checked at the end of the file if no __END__ or
__DATA__ block is present, and is checked before the __END__ or
__DATA__ block if such
On Sep 26, 2006, at 10:21 PM, Will Coleda wrote:
I took a first pass at a perlcritic test: t/codingstd/
perlcritic.t ; this test isn't run by default.
[snip]
Cool! Attached is a patch to simplify this test code a little bit by
leveraging Test::Perl::Critic. I also reworked
CodeLayout::Us
On Tue Sep 19 10:10:45 2006, [EMAIL PROTECTED] wrote:
> On Tuesday 19 September 2006 07:56, jerry gay wrote:
>
> > ~ all non-perl test files must have a shebang
> >
> > i strongly suggest that this be extended to cover all test files.
> > then, as you say, it can easily be tested, and it's value
I took a first pass at a perlcritic test: t/codingstd/perlcritic.t ;
this test isn't run by default.
It reports on only the following perlcritic rules at the moment:
TestingAndDebugging::RequireUseStrict
TestingAndDebugging::RequireUseWarnings
Variables::ProhibitConditionalDeclarat
On Tuesday 19 September 2006 07:56, jerry gay wrote:
> ~ all non-perl test files must have a shebang
>
> i strongly suggest that this be extended to cover all test files.
> then, as you say, it can easily be tested, and it's value can be used
> in other tests to determine it's file type. if you w
On 9/19/06, Paul Cochrane <[EMAIL PROTECTED]> wrote:
Jerry,
> all new rt tickets are created via parrotbug. it may not be sexy, but
> it's what we've got :-)
I'm not 100% sure if it worked, as parrotbug gave this warning:
Use of uninitialized value in concatenation (.) or string at
./parrotbug
Jerry,
all new rt tickets are created via parrotbug. it may not be sexy, but
it's what we've got :-)
I'm not 100% sure if it worked, as parrotbug gave this warning:
Use of uninitialized value in concatenation (.) or string at
./parrotbug line 525, line 7.
and the ticket doesn't seem to have
On 9/19/06, Paul Cochrane <[EMAIL PROTECTED]> wrote:
This is going to sound rather silly, but... how does one enter a new
ticket to RT? I've got an account, but can't see anywhere on
rt.perl.org where one can add a new ticket. There's also no help link
I can go to to work out what to do. Shou
Jerry,
oh, and yes, i believe the shebang should be in all perl files... but
this isn't specified *yet* in pdd07. if you can enter the ticket, that
would be fantastic, and we'll get a ruling from chip.
This is going to sound rather silly, but... how does one enter a new
ticket to RT? I've got
On 9/19/06, Paul Cochrane <[EMAIL PROTECTED]> wrote:
> firstly, line endings are unrelated to this effort and should be a
> separate patch. that's no biggie, and alone wouldn't stop me from
> applying.
I can do that in a separate patch if you want. That's not a major
problem, and probably a good
Jerry,
firstly, line endings are unrelated to this effort and should be a
separate patch. that's no biggie, and alone wouldn't stop me from
applying.
I can do that in a separate patch if you want. That's not a major
problem, and probably a good idea.
I'd not realised some of the issues you b
On 9/19/06, via RT Paul Cochrane <[EMAIL PROTECTED]> wrote:
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40361]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40361 >
This is a patch of more Pe
Hi Bernhard,
thanks for adding the codas in the Perl files.
No worries! I actually found some more perl files so will make the
necessary changes when I get the tuits.
Could you also provide a test in t/codingstd/code_coda.t, so that future
Perl files will automatically be checked?
Will do :
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40349]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40349 >
Hi,
This is a patch to (attempt to) close the Cage Cleaner's RT ticket
#40278. The
# New Ticket Created by Will Coleda
# Please include the string: [perl #40278]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40278 >
From the recently updated pdd07:
Perl source files must end with this block:
# Local V
36 matches
Mail list logo
