Thread: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Alvaro Herrera
Date:
Excerpts from Bruce Momjian's message of dom jun 10 15:20:34 -0400 2012: > Run pgindent on 9.2 source tree in preparation for first 9.3 > commit-fest. Hm, does this touch stuff that would also be modified by perltidy? I wonder if we should refrain from doing entab/detab on perl files and instead have perltidy touch such code. Perhaps the thing to do is ensure that perltidy also uses tabs instead of spaces. > src/tools/msvc/Install.pm | 1056 ++++++++++--------- > src/tools/msvc/MSBuildProject.pm | 325 +++--- > src/tools/msvc/Mkvcbuild.pm | 1278 ++++++++++++----------- > src/tools/msvc/Project.pm | 607 ++++++------ > src/tools/msvc/Solution.pm | 980 +++++++++--------- > src/tools/msvc/VCBuildProject.pm | 292 +++--- > src/tools/msvc/VSObjectFactory.pm | 152 ++-- > src/tools/msvc/build.pl | 20 +- > src/tools/msvc/builddoc.pl | 32 +- > src/tools/msvc/config_default.pl | 38 +- > src/tools/msvc/gendef.pl | 66 +- > src/tools/msvc/install.pl | 4 +- > src/tools/msvc/pgbison.pl | 14 +- > src/tools/msvc/pgflex.pl | 60 +- > src/tools/msvc/vcregress.pl | 400 ++++---- -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Bruce Momjian
Date:
On Sun, Jun 10, 2012 at 08:55:13PM -0400, Alvaro Herrera wrote: > > Excerpts from Bruce Momjian's message of dom jun 10 15:20:34 -0400 2012: > > Run pgindent on 9.2 source tree in preparation for first 9.3 > > commit-fest. > > Hm, does this touch stuff that would also be modified by perltidy? I > wonder if we should refrain from doing entab/detab on perl files and > instead have perltidy touch such code. > > > src/tools/msvc/Install.pm | 1056 ++++++++++--------- > > src/tools/msvc/MSBuildProject.pm | 325 +++--- > > src/tools/msvc/Mkvcbuild.pm | 1278 ++++++++++++----------- > > src/tools/msvc/Project.pm | 607 ++++++------ > > src/tools/msvc/Solution.pm | 980 +++++++++--------- > > src/tools/msvc/VCBuildProject.pm | 292 +++--- > > src/tools/msvc/VSObjectFactory.pm | 152 ++-- > > src/tools/msvc/build.pl | 20 +- > > src/tools/msvc/builddoc.pl | 32 +- > > src/tools/msvc/config_default.pl | 38 +- > > src/tools/msvc/gendef.pl | 66 +- > > src/tools/msvc/install.pl | 4 +- > > src/tools/msvc/pgbison.pl | 14 +- > > src/tools/msvc/pgflex.pl | 60 +- > > src/tools/msvc/vcregress.pl | 400 ++++---- The Perl files were modified by perltidy and not by pgindent, as documented in the pgindent README: 9) Indent the Perl MSVC code: cd src/tools/msvc perltidy -b -bl -nsfs -naws -l=100 -ole=unix *.pl *.pm > Perhaps the thing to do is ensure that perltidy also uses tabs instead > of spaces. If you would like 'entab' run on the Perl files, let me know. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Alvaro Herrera
Date:
Excerpts from Bruce Momjian's message of dom jun 10 22:37:14 -0400 2012: > > On Sun, Jun 10, 2012 at 08:55:13PM -0400, Alvaro Herrera wrote: > > > > Excerpts from Bruce Momjian's message of dom jun 10 15:20:34 -0400 2012: > > > Run pgindent on 9.2 source tree in preparation for first 9.3 > > > commit-fest. > > > > Hm, does this touch stuff that would also be modified by perltidy? I > > wonder if we should refrain from doing entab/detab on perl files and > > instead have perltidy touch such code. > The Perl files were modified by perltidy and not by pgindent, as > documented in the pgindent README: > > 9) Indent the Perl MSVC code: > > cd src/tools/msvc > perltidy -b -bl -nsfs -naws -l=100 -ole=unix *.pl *.pm Oh, I see. That's great then. Should those change be committed separately, just to avoid confusion? BTW those aren't the only Perl files in the source tree -- we also have the genbki stuff, for example. (There is already some inconsistency in tabs/spaces in genbki.pl already) > > Perhaps the thing to do is ensure that perltidy also uses tabs instead > > of spaces. > > If you would like 'entab' run on the Perl files, let me know. Whatever perltidy emits is fine with me, but should we consider passing -et=4 to perltidy? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Bruce Momjian
Date:
On Mon, Jun 11, 2012 at 12:20:13PM -0400, Alvaro Herrera wrote: > > > Hm, does this touch stuff that would also be modified by perltidy? I > > > wonder if we should refrain from doing entab/detab on perl files and > > > instead have perltidy touch such code. > > > The Perl files were modified by perltidy and not by pgindent, as > > documented in the pgindent README: > > > > 9) Indent the Perl MSVC code: > > > > cd src/tools/msvc > > perltidy -b -bl -nsfs -naws -l=100 -ole=unix *.pl *.pm > > Oh, I see. That's great then. Should those change be committed > separately, just to avoid confusion? BTW those aren't the only Perl Not sure. I just followed the README instructions. I should just probably mention the Perl files were not processed by pgindent on the commit. > files in the source tree -- we also have the genbki stuff, for example. > (There is already some inconsistency in tabs/spaces in genbki.pl > already) I was not aware of them. If you want them run, would you update the pgindent README to mention them please? > > > Perhaps the thing to do is ensure that perltidy also uses tabs instead > > > of spaces. > > > > If you would like 'entab' run on the Perl files, let me know. > > Whatever perltidy emits is fine with me, but should we consider passing > -et=4 to perltidy? No idea. I do not work in those files enough to have an opinion. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Alvaro Herrera
Date:
Excerpts from Bruce Momjian's message of lun jun 11 15:44:16 -0400 2012: > > On Mon, Jun 11, 2012 at 12:20:13PM -0400, Alvaro Herrera wrote: > > > > Hm, does this touch stuff that would also be modified by perltidy? I > > > > wonder if we should refrain from doing entab/detab on perl files and > > > > instead have perltidy touch such code. > > > > > The Perl files were modified by perltidy and not by pgindent, as > > > documented in the pgindent README: > > > > > > 9) Indent the Perl MSVC code: > > > > > > cd src/tools/msvc > > > perltidy -b -bl -nsfs -naws -l=100 -ole=unix *.pl *.pm > > > > Oh, I see. That's great then. Should those change be committed > > separately, just to avoid confusion? BTW those aren't the only Perl > > Not sure. I just followed the README instructions. I should just > probably mention the Perl files were not processed by pgindent on the > commit. Well, you wrote the instructions yourself :-) > > files in the source tree -- we also have the genbki stuff, for example. > > (There is already some inconsistency in tabs/spaces in genbki.pl > > already) > > I was not aware of them. If you want them run, would you update the > pgindent README to mention them please? What about something like this in the root of the tree: find . -name \*.pl -o -name \*.pm | xargs perltidy -b -bl -nsfs -naws -l=100 -ole=unix There are files all over the place. The file that would most be affected with one run of this is the ECPG grammar generator. I checked the "-et=4" business (which is basically entab). We're pretty inconsistent about tabs in perl code it seems; some files use tabs others use spaces. Honestly I would just settle on what we use on C files, even if the Perl devs don't recommend it "because of maintainability and portability". I mean if it works well for us for C code, why would it be a problem in Perl code? However, I don't write much of that Perl code myself. > > > > Perhaps the thing to do is ensure that perltidy also uses tabs instead > > > > of spaces. > > > > > > If you would like 'entab' run on the Perl files, let me know. > > > > Whatever perltidy emits is fine with me, but should we consider passing > > -et=4 to perltidy? > > No idea. I do not work in those files enough to have an opinion. What do others think? Maybe I'm just being obnoxious here for no useful gain. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Robert Haas
Date:
On Mon, Jun 11, 2012 at 5:57 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > What do others think? Maybe I'm just being obnoxious here for no useful > gain. I don't think you're being obnoxious; and I also agree with you on the substance of the issue. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Bruce Momjian
Date:
On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote: > > Excerpts from Bruce Momjian's message of lun jun 11 15:44:16 -0400 2012: > > > > On Mon, Jun 11, 2012 at 12:20:13PM -0400, Alvaro Herrera wrote: > > > > > Hm, does this touch stuff that would also be modified by perltidy? I > > > > > wonder if we should refrain from doing entab/detab on perl files and > > > > > instead have perltidy touch such code. > > > > > > > The Perl files were modified by perltidy and not by pgindent, as > > > > documented in the pgindent README: > > > > > > > > 9) Indent the Perl MSVC code: > > > > > > > > cd src/tools/msvc > > > > perltidy -b -bl -nsfs -naws -l=100 -ole=unix *.pl *.pm > > > > > > Oh, I see. That's great then. Should those change be committed > > > separately, just to avoid confusion? BTW those aren't the only Perl > > > > Not sure. I just followed the README instructions. I should just > > probably mention the Perl files were not processed by pgindent on the > > commit. > > Well, you wrote the instructions yourself :-) Well, initially, yes, but others have improved them over time. > > > files in the source tree -- we also have the genbki stuff, for example. > > > (There is already some inconsistency in tabs/spaces in genbki.pl > > > already) > > > > I was not aware of them. If you want them run, would you update the > > pgindent README to mention them please? > > What about something like this in the root of the tree: > find . -name \*.pl -o -name \*.pm | xargs perltidy -b -bl -nsfs -naws -l=100 -ole=unix > > There are files all over the place. The file that would most be > affected with one run of this is the ECPG grammar generator. Sounds like a good idea to me. > I checked the "-et=4" business (which is basically entab). We're pretty > inconsistent about tabs in perl code it seems; some files use tabs > others use spaces. Honestly I would just settle on what we use on C > files, even if the Perl devs don't recommend it "because of > maintainability and portability". I mean if it works well for us for C > code, why would it be a problem in Perl code? However, I don't write > much of that Perl code myself. Yes, I would love to hear a Perl person chime in here to tell us it is OK, as you stated. I suppose if we don't get any feedback in a few days, let's just go ahead and make the changes you suggested. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Noah Misch
Date:
On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote:
> What about something like this in the root of the tree:
> find . -name \*.pl -o -name \*.pm | xargs perltidy -b -bl -nsfs -naws -l=100 -ole=unix
>
> There are files all over the place. The file that would most be
> affected with one run of this is the ECPG grammar generator.
>
> I checked the "-et=4" business (which is basically entab). We're pretty
> inconsistent about tabs in perl code it seems; some files use tabs
> others use spaces. Honestly I would just settle on what we use on C
> files, even if the Perl devs don't recommend it "because of
> maintainability and portability". I mean if it works well for us for C
> code, why would it be a problem in Perl code? However, I don't write
> much of that Perl code myself.
+1 for formatting all our Perl scripts and for including -et=4. Since that
will rewrite currently-tidy files anyway, this is a good time to audit our
perltidy settings.
Why -l=100 instead of -l=78 like our C code?
perltidy changes this code:
for ($long_variable_name_to_initialize = 0; $long_variable_name_to_initialize < $long_limit_variable_name;
$long_variable_name_to_initialize++){
to this:
for ( $long_variable_name_to_initialize = 0; $long_variable_name_to_initialize < $long_limit_variable_name;
$long_variable_name_to_initialize++ ){
Using -vtc=2 removes the new trailing line break. Additionally using "-vt=2
-nsak=for" removes the new leading line break, but it also removes the space
between "for" and "(". Anyone know how to make perltidy format this like we
do in C code?
Why -naws? I would lean toward "-aws -dws -pt=2" to change code like this:
-my $dbi=DBI->connect('DBI:Pg:dbname='.$opt{d});
+my $dbi = DBI->connect('DBI:Pg:dbname=' . $opt{d});
I'd also consider -kbl=2 to preserve runs of blank lines that the author used
to delineate related groups of functions.
Thanks,
nm
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Bruce Momjian
Date:
On Tue, Jun 12, 2012 at 01:50:48PM -0400, Noah Misch wrote: > On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote: > > What about something like this in the root of the tree: > > find . -name \*.pl -o -name \*.pm | xargs perltidy -b -bl -nsfs -naws -l=100 -ole=unix > > > > There are files all over the place. The file that would most be > > affected with one run of this is the ECPG grammar generator. > > > > I checked the "-et=4" business (which is basically entab). We're pretty > > inconsistent about tabs in perl code it seems; some files use tabs > > others use spaces. Honestly I would just settle on what we use on C > > files, even if the Perl devs don't recommend it "because of > > maintainability and portability". I mean if it works well for us for C > > code, why would it be a problem in Perl code? However, I don't write > > much of that Perl code myself. > > +1 for formatting all our Perl scripts and for including -et=4. Since that > will rewrite currently-tidy files anyway, this is a good time to audit our > perltidy settings. OK, another open question is whether we should do any of these changes now for 9.2/9.3 or wait for 9.3/9.4? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Robert Haas
Date:
On Tue, Jun 12, 2012 at 2:02 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Tue, Jun 12, 2012 at 01:50:48PM -0400, Noah Misch wrote: >> On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote: >> > What about something like this in the root of the tree: >> > find . -name \*.pl -o -name \*.pm | xargs perltidy -b -bl -nsfs -naws -l=100 -ole=unix >> > >> > There are files all over the place. The file that would most be >> > affected with one run of this is the ECPG grammar generator. >> > >> > I checked the "-et=4" business (which is basically entab). We're pretty >> > inconsistent about tabs in perl code it seems; some files use tabs >> > others use spaces. Honestly I would just settle on what we use on C >> > files, even if the Perl devs don't recommend it "because of >> > maintainability and portability". I mean if it works well for us for C >> > code, why would it be a problem in Perl code? However, I don't write >> > much of that Perl code myself. >> >> +1 for formatting all our Perl scripts and for including -et=4. Since that >> will rewrite currently-tidy files anyway, this is a good time to audit our >> perltidy settings. > > OK, another open question is whether we should do any of these changes > now for 9.2/9.3 or wait for 9.3/9.4? I don't think it matters very much - very few commits touch those perl scripts. If we have a consensus, I think it's fine to do it now, or even after we branch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Bruce Momjian
Date:
On Tue, Jun 12, 2012 at 01:50:48PM -0400, Noah Misch wrote:
> On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote:
> > What about something like this in the root of the tree:
> > find . -name \*.pl -o -name \*.pm | xargs perltidy -b -bl -nsfs -naws -l=100 -ole=unix
> >
> > There are files all over the place. The file that would most be
> > affected with one run of this is the ECPG grammar generator.
> >
> > I checked the "-et=4" business (which is basically entab). We're pretty
> > inconsistent about tabs in perl code it seems; some files use tabs
> > others use spaces. Honestly I would just settle on what we use on C
> > files, even if the Perl devs don't recommend it "because of
> > maintainability and portability". I mean if it works well for us for C
> > code, why would it be a problem in Perl code? However, I don't write
> > much of that Perl code myself.
>
> +1 for formatting all our Perl scripts and for including -et=4. Since that
> will rewrite currently-tidy files anyway, this is a good time to audit our
> perltidy settings.
>
> Why -l=100 instead of -l=78 like our C code?
>
> perltidy changes this code:
>
> for ($long_variable_name_to_initialize = 0;
> $long_variable_name_to_initialize < $long_limit_variable_name;
> $long_variable_name_to_initialize++)
> {
>
> to this:
>
> for (
> $long_variable_name_to_initialize = 0;
> $long_variable_name_to_initialize < $long_limit_variable_name;
> $long_variable_name_to_initialize++
> )
> {
>
> Using -vtc=2 removes the new trailing line break. Additionally using "-vt=2
> -nsak=for" removes the new leading line break, but it also removes the space
> between "for" and "(". Anyone know how to make perltidy format this like we
> do in C code?
>
> Why -naws? I would lean toward "-aws -dws -pt=2" to change code like this:
>
> -my $dbi=DBI->connect('DBI:Pg:dbname='.$opt{d});
> +my $dbi = DBI->connect('DBI:Pg:dbname=' . $opt{d});
>
> I'd also consider -kbl=2 to preserve runs of blank lines that the author used
> to delineate related groups of functions.
OK, based on this feedback, I have updated the pgindent README to use
these Perl indent instructions:
find . -name \*.pl -o -name \*.pm | xargs perltidy \ --backup-and-modify-in-place
--opening-brace-on-new-line\ --vertical-tightness=2 --vertical-tightness-closing=2 \
--nospace-after-keyword=for--nospace-for-semicolon \ --add-whitespace --delete-old-whitespace --paren-tightness=2
\ --keep-old-blank-lines=2 --maximum-line-length=78 \ --entab-leading-whitespace=4
--output-line-ending=unix
Unless I hear otherwise, I will run this new command on the 9.2 and HEAD
Perl files.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Tom Lane
Date:
Bruce Momjian <bruce@momjian.us> writes:
> OK, based on this feedback, I have updated the pgindent README to use
> these Perl indent instructions:
> find . -name \*.pl -o -name \*.pm | xargs perltidy \
> --backup-and-modify-in-place --opening-brace-on-new-line \
> --vertical-tightness=2 --vertical-tightness-closing=2 \
> --nospace-after-keyword=for --nospace-for-semicolon \
> --add-whitespace --delete-old-whitespace --paren-tightness=2 \
> --keep-old-blank-lines=2 --maximum-line-length=78 \
> --entab-leading-whitespace=4 --output-line-ending=unix
> Unless I hear otherwise, I will run this new command on the 9.2 and HEAD
> Perl files.
No idea what all that stuff does. Would it be reasonable to post a diff
showing what this would do to the files in question?
regards, tom lane
Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Bruce Momjian
Date:
On Fri, Jun 15, 2012 at 10:48:27PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > OK, based on this feedback, I have updated the pgindent README to use > > these Perl indent instructions: > > > find . -name \*.pl -o -name \*.pm | xargs perltidy \ > > --backup-and-modify-in-place --opening-brace-on-new-line \ > > --vertical-tightness=2 --vertical-tightness-closing=2 \ > > --nospace-after-keyword=for --nospace-for-semicolon \ > > --add-whitespace --delete-old-whitespace --paren-tightness=2 \ > > --keep-old-blank-lines=2 --maximum-line-length=78 \ > > --entab-leading-whitespace=4 --output-line-ending=unix > > > Unless I hear otherwise, I will run this new command on the 9.2 and HEAD > > Perl files. > > No idea what all that stuff does. Would it be reasonable to post a diff > showing what this would do to the files in question? Sure: http://momjian.us/expire/perl.diff -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Noah Misch
Date:
On Fri, Jun 15, 2012 at 10:45:16PM -0400, Bruce Momjian wrote: > I have updated the pgindent README to use > these Perl indent instructions: > > find . -name \*.pl -o -name \*.pm | xargs perltidy \ > --backup-and-modify-in-place --opening-brace-on-new-line \ > --vertical-tightness=2 --vertical-tightness-closing=2 \ > --nospace-after-keyword=for --nospace-for-semicolon \ > --add-whitespace --delete-old-whitespace --paren-tightness=2 \ > --keep-old-blank-lines=2 --maximum-line-length=78 \ > --entab-leading-whitespace=4 --output-line-ending=unix I would lean against using --nospace-after-keyword=for. Not using it means we get wrong formatting when the for-loop conditions span multiple lines. Using it means we get wrong formatting (albeit less severe) on every for-loop. In any event, if we do use it for for-loops, we should probably use it for all control structure keywords. Otherwise, I like this. As a last idle idea, how about putting the options in a configuration file and passing --profile= as the only option? Besides keeping you from copying a 7-line shell command, this has the benefit of ignoring any ~/.perltidyrc. Thanks, nm
Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Bruce Momjian
Date:
On Sat, Jun 16, 2012 at 01:10:31AM -0400, Noah Misch wrote: > On Fri, Jun 15, 2012 at 10:45:16PM -0400, Bruce Momjian wrote: > > I have updated the pgindent README to use > > these Perl indent instructions: > > > > find . -name \*.pl -o -name \*.pm | xargs perltidy \ > > --backup-and-modify-in-place --opening-brace-on-new-line \ > > --vertical-tightness=2 --vertical-tightness-closing=2 \ > > --nospace-after-keyword=for --nospace-for-semicolon \ > > --add-whitespace --delete-old-whitespace --paren-tightness=2 \ > > --keep-old-blank-lines=2 --maximum-line-length=78 \ > > --entab-leading-whitespace=4 --output-line-ending=unix > > I would lean against using --nospace-after-keyword=for. Not using it means we > get wrong formatting when the for-loop conditions span multiple lines. Using > it means we get wrong formatting (albeit less severe) on every for-loop. In > any event, if we do use it for for-loops, we should probably use it for all > control structure keywords. Agreed, good point. > Otherwise, I like this. > > As a last idle idea, how about putting the options in a configuration file and > passing --profile= as the only option? Besides keeping you from copying a > 7-line shell command, this has the benefit of ignoring any ~/.perltidyrc. Also agreed, and change made. Perltidyrc now has: --add-whitespace--backup-and-modify-in-place--delete-old-whitespace--entab-leading-whitespace=4--keep-old-blank-lines=2--maximum-line-length=78--nospace-for-semicolon--opening-brace-on-new-line--output-line-ending=unix--paren-tightness=2--vertical-tightness=2--vertical-tightness-closing=2 -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3
From
Bruce Momjian
Date:
On Tue, Jun 12, 2012 at 02:40:09PM -0400, Robert Haas wrote: > On Tue, Jun 12, 2012 at 2:02 PM, Bruce Momjian <bruce@momjian.us> wrote: > > On Tue, Jun 12, 2012 at 01:50:48PM -0400, Noah Misch wrote: > >> On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote: > >> > What about something like this in the root of the tree: > >> > find . -name \*.pl -o -name \*.pm | xargs perltidy -b -bl -nsfs -naws -l=100 -ole=unix > >> > > >> > There are files all over the place. The file that would most be > >> > affected with one run of this is the ECPG grammar generator. > >> > > >> > I checked the "-et=4" business (which is basically entab). We're pretty > >> > inconsistent about tabs in perl code it seems; some files use tabs > >> > others use spaces. Honestly I would just settle on what we use on C > >> > files, even if the Perl devs don't recommend it "because of > >> > maintainability and portability". I mean if it works well for us for C > >> > code, why would it be a problem in Perl code? However, I don't write > >> > much of that Perl code myself. > >> > >> +1 for formatting all our Perl scripts and for including -et=4. Since that > >> will rewrite currently-tidy files anyway, this is a good time to audit our > >> perltidy settings. > > > > OK, another open question is whether we should do any of these changes > > now for 9.2/9.3 or wait for 9.3/9.4? > > I don't think it matters very much - very few commits touch those perl > scripts. If we have a consensus, I think it's fine to do it now, or > even after we branch. Done. Run on HEAD and 9.2 --- sorry for the delay. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +