Hacker News Reader

The title is One sentence per line, but he clarifies to include clauses in the body of the article. This also has nothing to do with where the margin ends, but editing text in developer formats that is later transformed to end-user formats in a way that gels well with the tools of the Unix environment. Your comment is unnecessarily venomous and not representative of the contents of the article.

View on HN

Have you noticed how Github helpfully shows which words have changed inside a line when looking at diffs? If we stop teaching people to bend over backwards to accomodate 70s technology, maybe we'll have more young hackers fixing our tools.

Diffs are only half the picture. Is git able to correctly merge two branches which each have single-word edits to a long-line sentence? I'm pretty sure it's not. I think the article is correctly arguing that we should continue to bend over backwards to accommodate 2012 technology.

> Have you noticed how Github helpfully shows which words have changed inside a line when looking at diffs?

GitHub's web UI only does a line diff. Which is not particularly helpful when you change a word or two in a six sentence paragraph. It's possible to do a word diff locally of course: `git diff --word-diff` but that's not the general use case for a code host, right now most code is line oriented and the UI suits it well. That is one of the reasons that the article advocates formatting thoughts with newlines, good portability. These input texts are closer to code than prose, so why format it like it was? Splitting thoughts into units digestible by your coding environment has the huge benefit of working with individual thoughts instead of individual paragraphs.

Reply on news.ycombinator.com