Hacker News Reader

Linus Torvalds answered exactly this question [0]. Not that that means you should unblinkingly take it on authority, but the original reasoning is: the renderer doesn't alway know when a line should be wrapped. Examples: a stack trace, or long log line, or essentially any other quoted artifact that has a specific pre-determined format.

The relevant quote from the link:

  Some things should not be word-wrapped. They may be some kind of
  quoted text - long compiler error messages, oops reports, whatever.
  Things that have a certain specific format.

  The tool displaying the thing can't know. The person writing the
  commit message can. End result: you'd better do word-wrapping at
  commit time, because that's the only time you know the difference.

[0] https://github.com/torvalds/linux/pull/17#issuecomment-56611...

EDIT: small clarification and formatting

I understand this rationale, but I think most developers will encounter commit messages written by bozos who don't press enter after every 72 characters, far more frequently than commit messages that contain stack traces or other fixed-format artifacts. (Disclosure: I am one of these bozos.) The tool flubs every non-wrapped paragraph just so it can preserve the occasional blob of ASCII art.

If the tool applied reasonable wrapping heuristics and got it wrong once in a while, it could easily offer a `--no-wrap` option to let users see the message exactly as it was composed.

Sounds like your markdown interpreter has an issue, or you're leaving lots of white space at the end of your lines.

Generally, in markdown, if you insert a line break, it won't translate to an explicit line break unless you put two in a row, or if there is 2+ spaces at the end of the line.

See [1] for an illustration

[1](https://johnmacfarlane.net/babelmark2/?text=This+line%0Ashou...)

Either behavior is allowed by the CommonMark spec, in fact.

> Why? Because the git CLI doesn't wrap properly?

First off, the commit message is plain text (by design) and can't be "wrapped" automatically, and any tool that tried would be insane.

The reason for 72 characters is that the CLI, like lots of other presentation mechanisms (including quoting in other commits or in code), wants to indent your message for readability. And the uniform standard width for terminals has been 80 characters for like four decades now.

Must it be? I dunno. I can imagine a uniform agreement among a broad team that everyone will assume a 100 character line and all tools should enforce that. Maybe a little more, but not that much because even on a modern screen you want to have two full terminals of text readable at a time.

But that's just a number. You'd still be told by your commit message style guide (or checkpatch.pl, or whatever) to wrap your lines manually at 92 characters. Is 25% more bytes on a line really worth yelling about?

> First off, the commit message is plain text (by design) and can't be "wrapped" automatically, and any tool that tried would be insane.

This text box I'm replying to you with is a plain text textbox. It word-wraps just fine.

There's myriads of plain text inputs and outputs you encounter every day and they all word wrap just fine.

The terminal is an aberration in that regard.

>This text box I'm replying to you with is a plain text textbox. It word-wraps just fine.

No it doesn't. In fact I had to edit a comment I made above this one about four times until I got the formatting right. It annoyingly ignored me doing this:

    line one
    line two
    line three

and assumed I meant this:

    line one line two line three

You're talking about the comment output, which is html after being processed. The text box is plaintext, and it word-wraps :)

The text box and the text output are the same thing: markdown. A little tickbox that just wrapped every message I send in a <pre> tag would be lovely.

You're missing my point because you don't understand the meaning I'm going for here. The comment box is not markdown, it's plaintext. This is not a rich text WYSIWYG editor.

My original point is that plenty of software does plaintext wrapping just fine and it's pretty ridiculous that consoles are stuck in this 80 character mindset.

No you're missing the point. A computer cannot wrap text reliably. It does not know how to.