Re: updated emacs configuration - Mailing list pgsql-hackers

From Tom Lane
Subject Re: updated emacs configuration
Date
Msg-id 1011.1372368714@sss.pgh.pa.us
Whole thread Raw
In response to Re: updated emacs configuration  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: updated emacs configuration  (Andres Freund <andres@2ndquadrant.com>)
Re: updated emacs configuration  (Bruce Momjian <bruce@momjian.us>)
Re: updated emacs configuration  (Greg Stark <stark@mit.edu>)
Re: updated emacs configuration  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Hash partitioning.
Next
From: Alvaro Herrera
Date:
Subject: Re: changeset generation v5-01 - Patches & git tree