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

On Tue, Aug 11, 2009 at 10:08 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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