pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

Started by Bruce Momjianover 13 years ago17 messages

bruce@momjian.us

over 13 years ago

Run pgindent on 9.2 source tree in preparation for first 9.3
commit-fest.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/927d61eeff78363ea3938c818d07e511ebaf75cf

Alvaro Herrera

alvherre@commandprompt.com

over 13 years ago

In reply to: Bruce Momjian (#1)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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

Bruce Momjian

bruce@momjian.us

over 13 years ago

In reply to: Alvaro Herrera (#2)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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. +

Alvaro Herrera

alvherre@commandprompt.com

over 13 years ago

In reply to: Bruce Momjian (#3)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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

Bruce Momjian

bruce@momjian.us

over 13 years ago

In reply to: Alvaro Herrera (#4)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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. +

Alvaro Herrera

alvherre@commandprompt.com

over 13 years ago

In reply to: Bruce Momjian (#5)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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

Robert Haas

robertmhaas@gmail.com

over 13 years ago

In reply to: Alvaro Herrera (#6)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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

Bruce Momjian

bruce@momjian.us

over 13 years ago

In reply to: Alvaro Herrera (#6)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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. +

Noah Misch

noah@leadboat.com

over 13 years ago

In reply to: Alvaro Herrera (#6)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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

#10

Bruce Momjian

bruce@momjian.us

over 13 years ago

In reply to: Noah Misch (#9)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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. +

#11

Robert Haas

robertmhaas@gmail.com

over 13 years ago

In reply to: Bruce Momjian (#10)

Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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

#12

Bruce Momjian

bruce@momjian.us

over 13 years ago

In reply to: Noah Misch (#9)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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. +

#13

Tom Lane

tgl@sss.pgh.pa.us

over 13 years ago

In reply to: Bruce Momjian (#12)

Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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

#14

Bruce Momjian

bruce@momjian.us

over 13 years ago

In reply to: Tom Lane (#13)

Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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. +

#15

Noah Misch

noah@leadboat.com

over 13 years ago

In reply to: Bruce Momjian (#12)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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

#16

Bruce Momjian

bruce@momjian.us

over 13 years ago

In reply to: Noah Misch (#15)

Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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. +

#17

Bruce Momjian

bruce@momjian.us

over 13 years ago

In reply to: Robert Haas (#11)

Re: Re: [COMMITTERS] pgsql: Run pgindent on 9.2 source tree in preparation for first 9.3

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. +