Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Date
Msg-id 603c8f070908111949p5533066dr1ebd28ec9bfea015@mail.gmail.com
Whole thread Raw
In response to Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Aug 11, 2009 at 10:08 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> What is a bit frustrating to me is that a number of Tom's changes to
>> the first two patches were trivial whitespace changes that required me
>> to rebase for no obvious reason.   Either those changes were made
>> accidentally as Tom was fooling around with what I had done, or they
>> were made because Tom had some reason to believe that they would play
>> more nicely with pgindent, though what those reasons may have been is
>> entirely opaque to me.
>
> I tend to do some manual adjustment to pgindent rules in places where
> I feel it makes the code more readable.  (Bear in mind that I've been
> looking at the Postgres code base for long enough that large variations
> from pgindent style are automatically less readable for me...)  If I'd
> realized you had followon patches touching the same spots I would've
> possibly refrained from that.  Although the nearby suggestions that we
> should run pgindent more often would render it moot ;-).
>
> If that's not it, you'd need to mention details.

Well, one thing I've noticed is that when a function prototype wraps
around to the next line, you often change the number of spaces in the
hanging indent.  I would do them the way that you want them if I could
figure out what the rule was, but I can't.  When I asked before, you
said that you let emacs do what it wants, but with apologies for using
the Other Editor, that doesn't actually help me very much.

I am also a bit confused about the rule for indenting the variables in
variable declarations.  I get that the *, if any, is suppose to hang
to the left of the name, so that the first character of each variable
name lines up - and in particular, line up on a tab stop.  But it's
not obvious to me how to choose which tab stop to line everything up
on.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Next
From: Jeff Janes
Date:
Subject: TODO: fix priority of ordering of read and write light-weight locks