Re: updated emacs configuration

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: updated emacs configuration
Date: 2013-06-27 21:31:54
Message-ID: 1011.1372368714@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Noah Misch wrote:
>> Note that emacs and pgindent remain at odds over interior tabs in comments.
>> When pgindent finds a double-space (typically after a sentence) ending at a
>> tab stop, it replaces the double-space with a tab. c-fill-paragraph will
>> convert that tab to a *single* space, and that can be enough to change many
>> line break positions.

> We should really stop pgindent from converting those double-spaces to
> tabs. Those tabs are later changed to three or four spaces when wording
> of the comment is changed, and things start looking very odd.

+1. That's probably the single most annoying bit of behavior in pgindent.
Being a two-spaces-after-a-period kind of guy, it might bite me more
often than other people, but now that somebody else has brought it up...

> Really, we should get out of patched BSD indent entirely already. How
> about astyle, for instance? I'm told that with some sensible options,
> the diff to what we have now is not very large, and several things
> actually become sensible (such as function pointer decls, which are
> messed up rather badly by pgindent)

AFAIR, no one has ever done a serious comparison to anything except GNU
indent, and (at least at the time) it seemed to have bugs as bad as
pgindent's, just different ones. I'm certainly open to another choice
as long as we don't lose on portability of the tool. But who will do
the legwork to test something else?

Probably the principal argument against switching to a different tool
has been that whitespace changes would complicate back-patching, but
I don't see why we couldn't solve that by re-indenting all the live back
branches at the time of the switch.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-06-27 21:33:04 Re: changeset generation v5-01 - Patches & git tree
Previous Message Jeff Janes 2013-06-27 21:30:38 Re: Hash partitioning.