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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Дата
Msg-id 603c8f070908111949p5533066dr1ebd28ec9bfea015@mail.gmail.com
обсуждение исходный текст
Ответ на 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>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Следующее
От: Jeff Janes
Дата:
Сообщение: TODO: fix priority of ordering of read and write light-weight locks