> Good email netiquette dictates we wrap our plain text emails (for) an 80 column terminal.
I think format should be separated from presentation and presuming people should use a particular display device is wrong. These are well established principles and Unix, although lacking a tradition of interface design, isn't some kind of exception.
* I use a modern email program (I use gmail but this would include, say, mutt).
* I sometimes use a wider terminal. Sometimes I use a narrower one. On my system (OS X default 10.6) less handles this just fine unless some 72-character-neckbeard screws it up.
* I sometimes use a GUI tool to examine messages, like github. These may be wider or narrower.
In all these cases forced 72 character wrappings look terrible.
I agree that ideally, you wouldn't wrap your text manually and your editor would do soft-wrapping, as well as any tools like `git log` or email programs that patches were read with, so the commit message would fit on any size screen.
In the real world, however, lots of people use editors that don't have good soft-wrap support turned on by default, meaning that they're going to be doing hard-wrapping at some width. `git log` does not do any wrapping of messages, so depending on your pager settings you either get the line going off the edge of the screen or being wrapped by your terminal with no regard for word breaks.
Furthermore, even when soft-wrap is supported, it sometimes makes text harder to read; if your window is wide, and it just uses the whole thing displaying 150 characters per line, it can make the text a lot harder to read than a nice narrow column of text. I have this problem on the web a lot; some sites use multiple columns which take up lots of horizontal space (under the assumption that everyone runs their browser full-screen), which makes me widen my window, but then I come across a site that just uses the whole width for one big block of text, which now has unreadably long lines.
Given that many of the tools in question don't support soft-wrapping usably, standardizing on 72-column hard wrapping is a reasonable approach. Lines don't come out unreadably long that way, they will be displayed reasonably in `git log` and other tools on standard-width terminals, and they will display well in 80-column email clients even with several levels of quoting.
I totally agree with this. Frankly, I don't think its too much to ask people to use modern software that is capable of very basic functionality like wrapping text. I find 72-column text with arbitrary (in the sense that the line breaks are at character-boundaries, not paragraph boundaries) line breaks incredibly hard to read.
For example:
I guess it also depends on who your audience is. Most of the devs I've
worked with use modern software, so long lines have never been an
issue for me. I could see where some teams would have a culture of
using more basic tools that it would become more of an issue. Of
course, typography plays a role, too. I don't generally use a
monospace font for reading normal text, and proportional fonts seem
to work better with this outdated style.
Wrapping text really muddles code. Ideally commit messages should have a different interface than your code, but in some cases people are going to be looking at it through a tool that is in more of a code-oriented space.
To be fair, thats a problem with the way browsers render anything inside the <pre> tag. If anything, it is an example of what people should do, not force unnecessary restrictions on the way they write text. Lest you might end up with:
> This is a short paragraph that I am quoting that
> someone
> else sent to me.
Or door 3: Let bad software stay bad, use good software instead and format our text naturally. If somebody chooses to use software that can't wrap text, that's fine for them personally — but I shouldn't have to deal with their artificial limitations.
The problem is with the way the archive web site decided to render this text.
From a web standpoint, the author of this email did the right thing: introduce very little formatting (only paragraph breaks) and leave it up to style sheets to render his text the way the reader wants it.
That's how you get the same text to render perfectly on a twenty column display (e.g. an old phone), a 30' inch monitor and everything in-between.
Introducing manual newlines at arbitrary points (e.g. 80 columns) is a bad practice that assumes that everyone will read your text on the same device.
I didn't say that all text ever should always be 72 columns in length. A git commit message and a Hacker News comment are used in completely different ways.
Also, I probably would have moved the ', so' to the next line, so that it reads a bit better.
Agreed: re: making sure that everyone can use it well, but targeting LCD will break newer devices sometimes. As far as I can tell, using linebreaks for linebreaks will give you readable output on the widest variety of devices.
> On an 80 column terminal
> Good email netiquette dictates we wrap our plain text emails (for) an 80 column terminal.
I think format should be separated from presentation and presuming people should use a particular display device is wrong. These are well established principles and Unix, although lacking a tradition of interface design, isn't some kind of exception.
* I use a modern email program (I use gmail but this would include, say, mutt).
* I sometimes use a wider terminal. Sometimes I use a narrower one. On my system (OS X default 10.6) less handles this just fine unless some 72-character-neckbeard screws it up.
* I sometimes use a GUI tool to examine messages, like github. These may be wider or narrower.
In all these cases forced 72 character wrappings look terrible.