[ returning from the wilds of Kentucky... ]
Stephen Frost <sfrost@snowman.net> writes:
> * Craig Ringer (craig@2ndquadrant.com) wrote:
>> Personally I'd be fine with 100 or so, but when I'm using buffers side by
>> side, or when I'm working in poor conditions where I've set my terminal to
>> "giant old people text" sizes, I remember the advantages of a width limit.
> I wouldn't be against 100 either really, but I don't really feel all
> that strongly either way. Then again, there is the back-patching pain
> which would ensue to consider..
Yeah. If we changed this, we'd have to adjust pgindent's settings to
match, whereupon it would immediately reflow every unprotected comment
block. When Bruce changed the effective right margin for comment blocks
by *one* column back around 8.1, pgindent changed enough places to cause
nasty back-patching pain for years afterward. I don't even want to
think about how much worse a 20-column change would be.
(Of course, we could avoid that problem by re-indenting all the active
back branches along with master ... but I bet we'd get push-back from
people maintaining external patch sets.)
Aside from that, I'm -1 on changing the target column width for pretty
much the same reasons other people have stated. I also agree with not
breaking error message texts across lines. Having them wrap is kind of
ugly, but it's tolerable, and moving the target width by 10 or 20
wouldn't make that situation very much better anyway.
I don't feel a strong need to touch existing code just to make it fit in
80 columns, but we could try to improve that situation whenever we have
to touch a function for other reasons.
regards, tom lane
