8 ms·

I'm curious about this: please do proper word-wrap and keep columns shorter than about 74 characters or so How come word-wrapping is left as a task for humans

I'm curious about this: please do proper word-wrap and keep columns shorter than about 74 characters or so How come word-wrapping is left as a task for humans here? Is there a technical/stylistic/cultural reason why lines can't be wrapped automatically to any desired width by the log presentation layer?

jacknagel 15y ago
git-log and friends indent the commit message by four spaces on the left, so wrapping at ~72 chars gives it symmetry on 80 column terminals. By wrapping it yourself, you decide where line breaks should be, not the presentation machinery. The optimal human-readable line length is something like 66 characters. It's much easier to quickly scan a log message that's 72 characters wide vs. one that is 200 characters wide.
- njonsson 15y ago
  Making semantic line breaks (such as for bullets) is understandable, but it still feels wrong that we’re otherwise doing the job of `fold`. I started breaking lines in commit messages because it’s convention, but I still believe this is a tooling issue. This shell script wraps wide commit messages to the width of your console. GIT_PAGER="fold -s -w`stty size | awk '{print $2}'` | less" git log $@
  - wnoise 15y ago
    You might be interested in the program "par", which uses dynamic programming to optimize the line breaks, and can automatically handle such things as text prefixed by "> ". http://www.nicemice.net/par/ http://www.nicemice.net/par/
- harlanlewis 15y ago
  Tangent time! "The optimal human-readable line length" isn't really something that exists, even if we make lots of assumptions about basic stuff like font size, avg word length, and color contrast. Here's a quick study on the reading speed and comprehension of character line lengths (cl) between 35 and 95 for reference: http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp http://psychology.wichita.edu/surl/usabilitynews/72/LineLeng... - most efficient reading (speed/accuracy) at 95cl - line length does not affect comprehension But here's the head spinner: - 60% _preferred_ either 35cl or 95cl - 100% _least preferred_ 35cl (45%) or 95cl (55%) Line length is an easy thing to assume everyone perceives the same way, but even given a consistent environment (definitely not a given in this age of increasingly diverse device dimensions) there's a wide range of preferences with little real impact on readability. Unless, of course, your assumptions about readability clash with the user's preferences or reading environment. Put simply - make your life easy and reduce problems by just letting the user decide.
kisielk 15y ago
Doesn't mean humans have to do it. When using vim for git commit messages it wraps them to 74 characters for me.
barumrho 15y ago
I hate to ask an off-topic question here, but is it considered good/bad practice to word-wrap plain text emails?
- telemachos 15y ago
  I think so, yes. Certainly, something like this is very common in Mutt configuration files: set editor="vim -c 'set tw=75 ft=mail noautoindent'" The 'set tw=75' bit, sets the text width to 75 columns.
  - JoshTriplett 15y ago
    Not actually necessary these days. vim knows to match the names used for mutt temporary files, and automatically puts uses mail mode and a sensible text width.
    - pyre 15y ago
      IIRC tw=72 is set whenever you change the filetype to 'mail'
- caf 15y ago
  This might not actually be that off-topic, because I think the underlying reason that git commit messages are stored line-wrapped is for ease of sending them unmolested through email.
- JoshTriplett 15y ago
  Good practice. If you don't word-wrap plain-text emails, each paragraph will show up as one long line; the program reading your mail on the other end can't wrap it automatically, because it might represent code, ASCII art, terminal transcripts, or something else that shouldn't get wrapped. So, wrap your paragraphs in plain-text email at some sensible column. Common convention suggests 72, because that allows for a few rounds of quoting before it passes 80.
JoshTriplett 15y ago
Because doing so would then require extra complexity to provide a syntax for lines that should not get wrapped, such as code, transcripts, tables, ASCII art... Hard-wrapping paragraphs to a desired length in the original log allows humans to decide which lines should wrap and which ones shouldn't, without a pile of complexity similar to HTML, Markdown, or some other markup language.
- codex 15y ago
  Couldn't our woes be solved with something as simple as soft-wrap with a tweak: soft-wrap: - to allow the presentation layer to soft-wrap a line, just don't add a newline. - for new paragraphs, just add two newlines as usual - for indent sensitive code, diagrams, etc. add newlines where appropriate, taking care to not exceed 74 columns for any line. Everyone does this already. + tweak: - in the presentation layer, soft-wrap all lines except those less than 74 characters long. This isn't perfect for terminals less than 80 characters wide, in that the diagrams won't fit, but nobody uses narrow terminals, and Linus' scheme is even more broken for this case, so it's strictly better. It also allows one to easily distinguish diagrams from non diagrams by eyeballing the text flow. Best of all, it makes fewer assumptions about terminal width.
  - JoshTriplett 15y ago
    Text that shouldn't wrap can exceed 74 characters. Some examples: log messages, transcripts, large tables. So, no, that wouldn't suffice.
    - timknauf 15y ago
      But how are those log messages, transcripts and large tables all that much better off under the current system? If a console is only 80 characters wide, they're still going to either disappear off the right edge or (as with most consoles I can think of) get soft-wrapped by the console anyway.
- atomicdog 15y ago
  >would then require extra complexity to provide a syntax for lines that should not get wrapped, And what's stopping someone implementing this?
nodata 15y ago
It makes the committer think longer about their commit message.

jacknagel 15y ago

git-log and friends indent the commit message by four spaces on the left, so wrapping at ~72 chars gives it symmetry on 80 column terminals. By wrapping it yourself, you decide where line breaks should be, not the presentation machinery. The optimal human-readable line length is something like 66 characters. It's much easier to quickly scan a log message that's 72 characters wide vs. one that is 200 characters wide.

njonsson 15y ago
Making semantic line breaks (such as for bullets) is understandable, but it still feels wrong that we’re otherwise doing the job of `fold`. I started breaking lines in commit messages because it’s convention, but I still believe this is a tooling issue. This shell script wraps wide commit messages to the width of your console. GIT_PAGER="fold -s -w`stty size | awk '{print $2}'` | less" git log $@
- wnoise 15y ago
  You might be interested in the program "par", which uses dynamic programming to optimize the line breaks, and can automatically handle such things as text prefixed by "> ". http://www.nicemice.net/par/ http://www.nicemice.net/par/
harlanlewis 15y ago
Tangent time! "The optimal human-readable line length" isn't really something that exists, even if we make lots of assumptions about basic stuff like font size, avg word length, and color contrast. Here's a quick study on the reading speed and comprehension of character line lengths (cl) between 35 and 95 for reference: http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp http://psychology.wichita.edu/surl/usabilitynews/72/LineLeng... - most efficient reading (speed/accuracy) at 95cl - line length does not affect comprehension But here's the head spinner: - 60% _preferred_ either 35cl or 95cl - 100% _least preferred_ 35cl (45%) or 95cl (55%) Line length is an easy thing to assume everyone perceives the same way, but even given a consistent environment (definitely not a given in this age of increasingly diverse device dimensions) there's a wide range of preferences with little real impact on readability. Unless, of course, your assumptions about readability clash with the user's preferences or reading environment. Put simply - make your life easy and reduce problems by just letting the user decide.

kisielk 15y ago

Doesn't mean humans have to do it. When using vim for git commit messages it wraps them to 74 characters for me.

barumrho 15y ago

I hate to ask an off-topic question here, but is it considered good/bad practice to word-wrap plain text emails?

telemachos 15y ago
I think so, yes. Certainly, something like this is very common in Mutt configuration files: set editor="vim -c 'set tw=75 ft=mail noautoindent'" The 'set tw=75' bit, sets the text width to 75 columns.
- JoshTriplett 15y ago
  Not actually necessary these days. vim knows to match the names used for mutt temporary files, and automatically puts uses mail mode and a sensible text width.
  - pyre 15y ago
    IIRC tw=72 is set whenever you change the filetype to 'mail'
caf 15y ago
This might not actually be that off-topic, because I think the underlying reason that git commit messages are stored line-wrapped is for ease of sending them unmolested through email.
JoshTriplett 15y ago
Good practice. If you don't word-wrap plain-text emails, each paragraph will show up as one long line; the program reading your mail on the other end can't wrap it automatically, because it might represent code, ASCII art, terminal transcripts, or something else that shouldn't get wrapped. So, wrap your paragraphs in plain-text email at some sensible column. Common convention suggests 72, because that allows for a few rounds of quoting before it passes 80.

JoshTriplett 15y ago

Because doing so would then require extra complexity to provide a syntax for lines that should not get wrapped, such as code, transcripts, tables, ASCII art... Hard-wrapping paragraphs to a desired length in the original log allows humans to decide which lines should wrap and which ones shouldn't, without a pile of complexity similar to HTML, Markdown, or some other markup language.

codex 15y ago
Couldn't our woes be solved with something as simple as soft-wrap with a tweak: soft-wrap: - to allow the presentation layer to soft-wrap a line, just don't add a newline. - for new paragraphs, just add two newlines as usual - for indent sensitive code, diagrams, etc. add newlines where appropriate, taking care to not exceed 74 columns for any line. Everyone does this already. + tweak: - in the presentation layer, soft-wrap all lines except those less than 74 characters long. This isn't perfect for terminals less than 80 characters wide, in that the diagrams won't fit, but nobody uses narrow terminals, and Linus' scheme is even more broken for this case, so it's strictly better. It also allows one to easily distinguish diagrams from non diagrams by eyeballing the text flow. Best of all, it makes fewer assumptions about terminal width.
- JoshTriplett 15y ago
  Text that shouldn't wrap can exceed 74 characters. Some examples: log messages, transcripts, large tables. So, no, that wouldn't suffice.
  - timknauf 15y ago
    But how are those log messages, transcripts and large tables all that much better off under the current system? If a console is only 80 characters wide, they're still going to either disappear off the right edge or (as with most consoles I can think of) get soft-wrapped by the console anyway.
atomicdog 15y ago
>would then require extra complexity to provide a syntax for lines that should not get wrapped, And what's stopping someone implementing this?

nodata 15y ago

It makes the committer think longer about their commit message.