Hacker News Reader

Comment by lutusp | Hacker News Reader

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

Complete thoughts reside in paragraphs, groupings of sentences, not in the sentences. One paragraph per line, please.

http://en.wikipedia.org/wiki/Wikipedia:Dont_use_line_breaks

A quote: "Do not use manually entered hard line breaks within paragraphs when editing articles."

A long list of justifications follows in the article.

View on HN

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.

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

> a list of items meant to appear as individual lines, that should not be merged.

Do you literally mean a list, like LaTeX itemize, description, or enumerate? Then the markup (whatever it is) should indicate that. In plain text that was going to remain in plain text form, I would put list items with double line breaks between them, and leading asterisks. This avoids any ambiguity. I don't know any other scenario where I would want the items to appear as individual lines, but not as paragraphs.

> Wouldn't it be better to revise diff so that it presents a subset of a paragraph containing the difference text

As I already said, some diff algorithms already do that, but as far as I know there are NO merge algorithms that do it. (BTW just in case of terminological confusion: when I say "merge algorithm" I'm referring to version control-style merging of edits; when you say "merge algorithm" you're referring to paragraph-merging, the process of putting multiple lines together into a single paragraph.)

> Diff and merge algorithms are line-oriented.

No, diff and merge algorithms are symbol-oriented.

For reasons that are as historical as they are technical, most diff and merge programs choose to break documents up on a line level of granularity in order to produce the symbols that are passed into the algorithm. But that's a design decision, not a technical one.

A diff/merge program that operates at a word level of granularity should be just as capable of handling two words edited on the same line as a line-oriented diff program is of handling two lines edited in the same function.

> The post proposes a single line-break after each clause or sentence, and then a double line-break after each paragraph.

It's a lot easier to rewrite the typographical conventions a piece of software conforms to than it is to rewrite the typographical conventions that millions of humans grew up using. Teaching the diff/merge program to recognize that CRLF isn't the only text boundary out there would achieve the same effect* at much lower cost.

*I realize that abbreviations complicate it somewhat. I'd submit, though, that if a basic diff/merge program is being relied on too closely in a scenario where that actually causes any consequential problems then the real error might be between Mr. Diff User's keyboard and chair. For normal diff usage 'failed' symbol boundary determinations like that are fine, the same as how a traditional line-oriented diff program doesn't critically suffer from the way it would interpret me inserting a carriage return into a line of code.

> No, diff and merge algorithms are symbol-oriented.

Point taken, and as soon as someone puts word-by-word merging into svn or git, I'll change my opinion.

> I'd submit, though, that if a basic diff/merge program is being relied on too closely in a scenario where that actually causes any consequential problems

[EDIT removed some response -- maybe "that" referred to a narrower scenario than I thought and parent didn't intend any insult.]

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.

Thank you.

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

Is it? I haven't seen LaTeX do it wrong yet. Of course, I use actual formatting code to specify format -- what I'd give to someone else is the rendered document, not the LaTeX source.

Reply on news.ycombinator.com