Re: updated emacs configuration

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: updated emacs configuration
Дата
Msg-id 1011.1372368714@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: updated emacs configuration  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Hash partitioning.
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: changeset generation v5-01 - Patches & git tree