Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

One sentence per line, please

rhodesmill.org

Post reply on HN
Print view View original

21–30 of 36 posts

Re: One sentence per line, please

#21

Post by jdp »

Camillo wrote: post #17
jdp wrote: post #16

Earlier quoted context omitted.

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.

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.

> 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.

Re: One sentence per line, please

#22

Post by lmm »

I found the incredibly thin page unreadable (had to use Clearly). One sentence per line makes sense for the "source" that you edit, but use something like Latex or Markdown so that we don't have to read it in that form.

Re: One sentence per line, please

#23

Post by lutusp »

georgebashi wrote: post #20
lutusp wrote: post #14

> One sentence per line, please I beg to differ: One paragraph per line, please. The natural lexical unit is not the sentence, but the paragraph. These three sentences belong together as a unit, and should be separated from other paragraphs by a double linefeed. If someone wants to later break paragraphs into separate sentences for some reason, it's child's play, and that option is implicit in this formatting. But if…

Your link was broken, I found it here: http://en.wikipedia.org/wiki/Wikipedia:Don%27t_use_line_brea...

Yes, and (arrgghh) too late to edit the original.

Thanks.

Re: One sentence per line, please

#24

Post by jmmcd »

lutusp wrote: post #14

> One sentence per line, please I beg to differ: One paragraph per line, please. The natural lexical unit is not the sentence, but the paragraph. These three sentences belong together as a unit, and should be separated from other paragraphs by a double linefeed. If someone wants to later break paragraphs into separate sentences for some reason, it's child's play, and that option is implicit in this formatting. But if…

Diff and merge algorithms are line-oriented. If a whole paragraph is on one line, and I edit one word, then the diff consists of the whole paragraph, which is bad. Some tools are able to do word-by-word diffs, as mentioned below. But none are able to merge correctly in the scenario where two branches have each edited one word in the same line.

I rarely edit Wikipedia so I don't know what its diff algorithm does. But I'm pretty sure it doesn't do any merging in any scenario, so that partly explains why one clause per line would not help there. That's quite different from Sphinx and TeX, which are usually stored in merge-capable version control. I think all of Wikipedia's justifications are specific to the case of editing in a text-box on the web and without diff/merge algorithms.

> if someone wants to reassemble individual sentences into paragraphs, as anyone knows who has tried to reassemble lines into paragraphs (as with an e-mail in its delivered form), it's nearly impossible to get right.

The post proposes a single line-break after each clause or sentence, and then a double line-break after each paragraph. TeX and Sphinx do the right thing in those cases.

Re: One sentence per line, please

#25

Post by lutusp »

jmmcd wrote: post #24
lutusp wrote: post #14

> One sentence per line, please I beg to differ: One paragraph per line, please. The natural lexical unit is not the sentence, but the paragraph. These three sentences belong together as a unit, and should be separated from other paragraphs by a double linefeed. If someone wants to later break paragraphs into separate sentences for some reason, it's child's play, and that option is implicit in this formatting. But if…

Diff and merge algorithms are line-oriented. If a whole paragraph is on one line, and I edit one word, then the diff consists of the whole paragraph, which is bad. Some tools are able to do word-by-word diffs, as mentioned below. But none are able to merge correctly in the scenario where two branches have each edited one word in the same line. I rarely edit Wikipedia so I don't know what its diff algorithm does. But…

> If a whole paragraph is on one line, and I edit one word, then the diff consists of the whole paragraph, which is bad.

Yes, bad although logical. It's a shame we can't have one optimal convention for all common text that appears naturally in paragraph form. Absent diff and similar programs, lexical units consisting of paragraphs is the obvious choice.

> The post proposes a single line-break after each clause or sentence ...

Yes, which is the convention used in e-mail and elsewhere. But it throws away formatting information that can't be recovered (see below for the reason). Wouldn't it be better to revise diff so that it presents a subset of a paragraph containing the difference text, instead of having to break up the source document just to make diff happy?

Obviously if the text diff processes consists of programming source files, this issue may not be important. But in the general case, text naturally consists of paragraphs, not sentences, and to change text to make diff happy puts the cart before the horse.

The problem with recombining broken text is never more obvious than the case of a paragraph, broken into lines that will need to be merged, followed by a list of items meant to appear as individual lines, that should not be merged. A merge algorithm cannot distinguish the two cases in a deterministic way.

Re: One sentence per line, please

#26

Post by tommorris »

lutusp wrote: post #23
georgebashi wrote: post #20

Earlier quoted context omitted.

Your link was broken, I found it here: http://en.wikipedia.org/wiki/Wikipedia:Don%27t_use_line_brea...

Yes, and (arrgghh) too late to edit the original. Thanks.

I've made the original link into a redirect.

Re: One sentence per line, please

#27

Post by lutusp »

keithpeter wrote: post #5
CJefferson wrote: post #3

Or, you can use a diff command which understands word diffs. git has '--word-diff', svn unfortunatly doesn't have such an option, but ' http://www.sable.mcgill.ca/~cpicke/swd/ provides a nice script (there are others). Don't know about mercurial. I hate working with authors who try to force line breaks into text unnaturally. I have heard many justifications for it over the years, but I find it hard to understand why…

The original article did say "In the tutorial, I ask students whether or not the Sphinx text files in their project will be read by end-users." I certainly would not send a file with 'semantic linefeeds' to anyone else . I use markdown quite a lot and LaTeX a little, so I'm happy with source file -> formatter -> file for reading The humble fmt (Linux) deals with a file with 'semantic line feeds' and produces reasonab…

> I'm sure someone will come up with a regexp that can take a 'standard' text file and split the lines on full stops and commas to restore an edited readable text file to 'semantic linefeed' source, thus allowing round trip copy editing.

Yes to the first, no to the second. The reason is that the act of recombining lines into paragraphs makes the assumption that lines broken by single linefeeds need to be merged into a paragraph. But in text, a list of items, meant to be read as a list, is also broken by single line feeds, and must not be turned into a paragraph.

One often sees posts here by beginners that include a list of items, but the rendered version assembles the list into a (typically unreadable) paragraph. More experienced hands know to break the list up with double linefeeds to defeat the "intelligent" reformatting algorithm.

The bottom line is that a recombining algorithm cannot distinguish a list of items from a paragraph of individual lines. The act of breaking text into lines loses information irretrievably.

Allow me a prediction: All these conventions that break text into individual lines and then try to reassemble them, i.e. this forum, the e-mail convention, and a thousand other examples, will eventually be abandoned in favor of leaving the text alone. This will happen when people realize they're throwing away information that cannot be recovered.

When I wrote Apple Writer in the late 1970s, the first change I made to common practice was retain the paragraph structure people naturally used in entering text (even though the displayed text was broken into lines on word boundaries). At the time, this was a bigger departure than it is now, and it helped make my program successful. But if I had been told then that people would still be defending the practice of breaking text into individual lines 35 years later, I would have laughed out loud.

Re: One sentence per line, please

#29

Post by keithpeter »

lutusp wrote: post #27
keithpeter wrote: post #5

Earlier quoted context omitted.

The original article did say "In the tutorial, I ask students whether or not the Sphinx text files in their project will be read by end-users." I certainly would not send a file with 'semantic linefeeds' to anyone else . I use markdown quite a lot and LaTeX a little, so I'm happy with source file -> formatter -> file for reading The humble fmt (Linux) deals with a file with 'semantic line feeds' and produces reasonab…

> I'm sure someone will come up with a regexp that can take a 'standard' text file and split the lines on full stops and commas to restore an edited readable text file to 'semantic linefeed' source, thus allowing round trip copy editing. Yes to the first, no to the second. The reason is that the act of recombining lines into paragraphs makes the assumption that lines broken by single linefeeds need to be merged into…

point taken for plain text files, but I use markdown so list items have asterisks at beginning of the line, so I have a pattern to distinguish list items from flowing text.

"But if I had been told then that people would still be defending the practice of breaking text into individual lines 35 years later, I would have laughed out loud."

Laughing is good for you! If I read you right, you invented the soft line wrap? Excellent!

Re: One sentence per line, please

#30

Post by tgb »

I've been using semantic line breaks for a while for LaTeX since, using Vim, this is the only editing style that is sane on default settings. But that shouldn't necessarily be true; what can I do to make vim friendlier to work with files that are one-paragraph-per-line or similarly formatted? I'm not particularly concerned about version control just editing.
Post reply on HN