pgindent and line length

Lists: pgsql-hackers
From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: pgindent and line length
Date: 2011-01-25 00:01:01
Message-ID: 1295913661.13617.5.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Somehow, pgindent appears to have this approach to push lines that are
longer than the defined line length limit back to the left to make it
fit. That results in something like this:

printfPQExpBuffer(&buf,
"SELECT n.nspname as \"%s\",\n"
" p.proname AS \"%s\",\n"
" pg_catalog.format_type(p.prorettype, NULL) AS \"%s\",\n",
gettext_noop("Schema"),
gettext_noop("Name"),
gettext_noop("Result data type"));

where the third line of the string was moved to the left.

I don't think this behavior is useful. If the line is too long and
cannot be split, then it is still more useful to be able locate the
start of the line in an expected position than to have the end of the
line on the hypothetical screen. You'll have to scroll right anyway
because there are usually lines that are going to be too long anyway.

Can we get rid of this behavior?


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgindent and line length
Date: 2011-01-25 03:02:34
Message-ID: 201101250302.p0P32Y911232@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut wrote:
> Somehow, pgindent appears to have this approach to push lines that are
> longer than the defined line length limit back to the left to make it
> fit. That results in something like this:
>
> printfPQExpBuffer(&buf,
> "SELECT n.nspname as \"%s\",\n"
> " p.proname AS \"%s\",\n"
> " pg_catalog.format_type(p.prorettype, NULL) AS \"%s\",\n",
> gettext_noop("Schema"),
> gettext_noop("Name"),
> gettext_noop("Result data type"));
>
> where the third line of the string was moved to the left.
>
> I don't think this behavior is useful. If the line is too long and
> cannot be split, then it is still more useful to be able locate the
> start of the line in an expected position than to have the end of the
> line on the hypothetical screen. You'll have to scroll right anyway
> because there are usually lines that are going to be too long anyway.
>
> Can we get rid of this behavior?

I think we will have to switch to another indent binary to do that
because it is done by BSD indent and I can't think of a way of fixing it
with pre or post processing.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgindent and line length
Date: 2011-01-25 03:13:32
Message-ID: 4515.1295925212@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Peter Eisentraut wrote:
>> Somehow, pgindent appears to have this approach to push lines that are
>> longer than the defined line length limit back to the left to make it
>> fit. That results in something like this:
>>
>> Can we get rid of this behavior?

> I think we will have to switch to another indent binary to do that
> because it is done by BSD indent and I can't think of a way of fixing it
> with pre or post processing.

Whether it's fixable or not, I'm going to vote against any change that
will result in any significant number of whitespace changes, because the
pain that will create for back-patching will far outweigh any minor
visual improvements. I'm still carrying the scars from dealing with
the ill-considered change in comment wrapping rules back around 8.1.
That caused me significant hassle on a regular basis for *years*.

regards, tom lane