Horton

Re: Preliminary results for proposed new pgindent implementation

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Bruce Momjian <bruce@momjian.us>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Piotr Stefaniak <postgres@piotr-stefaniak.me>
Date: 2017-06-16T18:11:58Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2017-06-16 13:44:30 -0400, Bruce Momjian wrote:
>> Yes, it is all about <80 column output.  The current pgindent does
>> everything possible to accomplish that --- the question is whether we
>> want uglier code to do it.

> For me personally the misindentation is way uglier than a too long line.

I'm coming around to that opinion too.  We have many source lines that
are a bit too long, or a lot too long if someone decided they didn't
want to split an error message across lines.  pgindent "fixes" that
in some places but not others (if it would have to go left of the
prevailing statement indent, it gives up and indents to the paren level
anyway).  On balance it's just weird.  Better to indent normally and
let the programmer decide if she wants to break the lines differently
to keep them from wrapping.

I assume though that Piotr wants an option to preserve that behavior.
I'm happy to write up a patch for bsdindent that adds a switch
controlling this, but is there any rhyme or reason to the way its
switches are named?

			regards, tom lane

Commits

  1. Manually un-break a few URLs that pgindent used to insist on splitting.

  2. Remove entab and associated detritus.

  3. Phase 3 of pgindent updates.

  4. Phase 2 of pgindent updates.

  5. Initial pgindent run with pg_bsd_indent version 2.0.

  6. Adjust pgindent script to use pg_bsd_indent 2.0.

  7. Final pgindent run with old pg_bsd_indent (version 1.3).