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 | 603c8f070908120657n2b16fd50y5480bf8af1d7e1d3@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY) (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
On Wed, Aug 12, 2009 at 9:38 AM, Alvaro Herrera<alvherre@commandprompt.com> wrote: > Robert Haas escribió: >> On Wed, Aug 12, 2009 at 12:27 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > >> > Ah. That's a bit idiosyncratic to pgindent. What it does for a >> > function definition makes sense, I think: it lines up all the >> > parameters to start in the same column: > >> That is truly bizarre. +1 from me for doing something that a >> competent C programmer can figure out without a calculator. I don't >> care what the rule is particularly, as long as it's obvious how to >> follow it. (In my own code I indent all of my continuation lines by >> one additional 4-space tab-stop. I realize this would be a horrible >> idea for PG since we don't want to change anything that's going to >> reindent the entire code base, and you might all hate it for other >> reasons anyway, but the point is that any idiot can look at it and >> figure out how it's supposed to be indented, because the rule is >> simple.) > > Well, the rule here is simple too (set cinoptions=(0 if you're > Vim-enabled). It's only function prototypes that are a bit weird, and > once you understand how it works it's trivial to reproduce. Function prototypes was what I was referring to. I think I understand how to reproduce it now, but it's still bizarre. ...Robert
В списке pgsql-hackers по дате отправления: