Alright, i am if not convinced then at leadt outnumbered. :-) Let me
do some tests with the merges and I will make a new release shortly
and then do the perltidy.
--
http://localrobot.com/
On May 12, 2010, at 9:03, Charlie Brady > wrote:
+1
On Wed, 12 May 2010, Robin Bowes wrote:
> On 12/05/10 07:00, Ask Bjørn Hansen wrote:
> >
> > On May 11, 2010, at 21:25, Robert Spier wrote:
> >
> >> Does anyone else have any opinions on doing a massive perltidy?
> >> I'm on the fence.
> >
>
On May 11, 2010, at 11:00 PM, Ask Bjørn Hansen wrote:
> On May 11, 2010, at 21:25, Robert Spier wrote:
>
>> Does anyone else have any opinions on doing a massive perltidy? I'm
>> on the fence.
>
> I'm on the fence, too. My concern is mostly for the people w
On 12/05/10 07:00, Ask Bjørn Hansen wrote:
>
> On May 11, 2010, at 21:25, Robert Spier wrote:
>
>> Does anyone else have any opinions on doing a massive perltidy?
>> I'm on the fence.
>
> I'm on the fence, too. My concern is mostly for the people with
&
On May 11, 2010, at 21:25, Robert Spier wrote:
> Does anyone else have any opinions on doing a massive perltidy? I'm
> on the fence.
I'm on the fence, too. My concern is mostly for the people with private
patches / hacked up versions. (Maybe that makes less sense than
On 12. mai 2010, at 06.25, Robert Spier wrote:
> Does anyone else have any opinions on doing a massive perltidy? I'm
> on the fence.
I say: Do it.
-J
Does anyone else have any opinions on doing a massive perltidy? I'm
on the fence.
At the very least I'd go for the equivalent of a M-x untabify, but at
the point you're doing that, it's almost worth going all the day.
-R
dhered to when making submissions.
It will also let me install a git pre-commit hook that automatically runs
perltidy on the files I'm changing. If I do that now, it will almost certainly
make all the patches I submit much larger. I'm of the opinion that whitespace
changes such as cha
daid slowly, or just rip it off? I've been on
the mailing list a very, very short time and I've already seen two
issues that perltidy uniformity would have prevented.
If we were to just fix the "big issues", I think that would help most
places without causing the huge ch
erltidyrc file in the git repo.
>
> There's also a lot of code that uses tab indents, 2 space indents, and 4
> space indents. And of course, code that uses a mixture of the three, with
> local variations thrown in for good measure.
>
> I figure that the least invasive time
me to do a wholesale perltidy is right after
a release, when most of the outstanding patches and forks that will get merged
in already have been. And a whitespace change should not be combined with other
changes. So I did this on my fork:
find . -name '*.pm' -exec perltidy -b {} \;
On Fri, 3 Apr 2009, Jared Johnson wrote:
Both nbbc and msc relate to perltidy adding whitespace to set apart comments.
[-nbcc], -bbc, --blanks-before-comments
A blank line will be introduced before a full-line comment.
This is the default. Use -nbbc or --noblanks-before
Both nbbc and msc relate to perltidy adding whitespace to set apart
comments.
[-nbcc], -bbc, --blanks-before-comments
A blank line will be introduced before a full-line
comment. This is the default. Use -nbbc or
--noblanks-before-comments to prevent such blank lines
Matt Sergeant wrote:
On Fri, 3 Apr 2009 08:38:59 -0500, Jared Johnson wrote:
first of all, kudos on the frequent releasing :)
I've attached a suggested patch to .perltidyrc. I've been playing
around with perltidy'ing all QP code and some results I don't like.
This doesn't fix all the things
ents
>A blank line will be introduced before a full-line
> comment. This is the default. Use -nbbc or
> --noblanks-before-comments to prevent such blank lines from being
> introduced.
No idea what this does? Do you have a visual example?
> -msc=n, --minimum-space
[-nbcc], -bbc, --blanks-before-comments
typo'd my interposition there, it's -nbbc
-Jared
[-nbcc], -bbc, --blanks-before-comments
A blank line will be introduced before a full-line comment.
This is the default. Use -nbbc or --noblanks-before-comments to
prevent such blank lines from being introduced.
-msc=n, --minimum-space-to-comment=n
Side co
Peter J. Holzer skribis 2005-07-17 16:28 (+0200):
> I usually start continuation lines below the matching element in the
> line above, so they are usually indented more than 2 or 4 spaces, like
> this:
> $foo = Foo::Bar->gazonk(a - long,
> line /
>
On 2005-07-17 10:04:27 -0400, John Peacock wrote:
> Robin Bowes wrote:
> >>>(any chance we can settle on 4 space indents instead of 2? Two
> >>>spaces hurts my eyes...)
> >>
> >>
> >>
> >>I vastly prefer 2 spaces. :-)
> >
> >
> >+1 (takes up less width)
-1. I find 4 spaces more readable.
> The
Robin Bowes wrote:
I believe it can do either. There is a defautl, but you can pretty much
customise what the output looks like according to your preferences.
Yes, you can do cuddled else's or not; I think the default is not, so that makes
Ask happy.
(any chance we can settle on 4 space inde
Ask Bjørn Hansen wrote:
I was going to suggest waiting for Robert to sync the perl.org
installation; but he can just sync to 0.31.
Does it do
if (...) {
...
} else {
...
}
or
if (...) {
...
}
else {
...
}
In the general case I find the latter much better.
I believe it can do eith
On Jul 15, 2005, at 2:40 PM, Matt Sergeant wrote:
[ let the bike-shedding begin ]
Would now be a good time to run perltidy on the trunk, since we're
landing all those other big changes anyway...?
I was going to suggest waiting for Robert to sync the perl.org
installation; but he can
Would now be a good time to run perltidy on the trunk, since we're
landing all those other big changes anyway...?
(any chance we can settle on 4 space indents instead of 2? Two spaces
hurts my eyes...)
23 matches
Mail list logo
