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
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 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
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 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
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, 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,
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:
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,
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:
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
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
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 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
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
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
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
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
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
My vote is on removing all emacs and vim settings from our source code
files.
and so you can get really bad code appearance.
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
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
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
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
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
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 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:
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
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
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
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
31 matches
Mail list logo
