Re: [HACKERS] Preliminary results for proposed new pgindent implementation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Preliminary results for proposed new pgindent implementation
Date
Msg-id 11868.1497636718@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Preliminary results for proposed new pgindentimplementation  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Preliminary results for proposed new pgindentimplementation  (Piotr Stefaniak <postgres@piotr-stefaniak.me>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Preliminary results for proposed new pgindentimplementation
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Preliminary results for proposed new pgindent implementation