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

31–36 of 36 posts

Re: One sentence per line, please

#31

Post by kd0amg »

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…

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.

Re: One sentence per line, please

#32

Post by jmmcd »

lutusp wrote: post #25
jmmcd wrote: post #24

Earlier quoted context omitted.

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 sen…

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

Re: One sentence per line, please

#33

Post by bunderbunder »

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…

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

Re: One sentence per line, please

#34

Post by jmmcd »

bunderbunder wrote: post #33
jmmcd wrote: post #24

Earlier quoted context omitted.

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…

> 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 gr…

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

Re: One sentence per line, please

#35

Post by jmuhlich »

cpeterso wrote: post #11
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…

I find myself adapting my coding style in order to produce prettier diffs (for code reviewers). For example, I may insert extra vertical whitespace or place a new function's definition where it won't be melded with unrelated diff chunks. I've played around with Bram Cohen's "patience" diff algorithm, but I can only remember a couple times when it produced a better diff.

"git add -p" is wonderful for this. In a nutshell, git has line-level granularity for committing, instead of file-level granularity (I know it's technically more complex than that). When you add a file for committing with -p, you interactively choose only the diff hunks you want and leave the others behind for a future commit. Plus you can split the hunks if they aren't fine-grained enough for you.

Re: One sentence per line, please

#36

Post by keithpeter »

http://vanemden.wordpress.com/2009/01/01/ventilated-prose/

'Ventilated Prose' was a term used by Buckminster Fuller. The blog author linked above is drafting rapidly, then adding line breaks after each sentence/clause as an editing aid. He mentions Vi and the use of dif

http://lists.canonical.org/pipermail/kragen-discuss/2008-Mar...

Found in the comments to the blog post linked above. Just parking these for the inevitable return of this topic.

Post reply on HN