4 ms·

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

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/ 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 anyone would do it, other than because their tools (soft word wrap in the editor, word-based diffing) are terrible.

keithpeter 14y ago
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 reasonable paragraphs. I think I will try this out as a lot of text editors have line oriented tools. It might be that the result of a lot of rearranging that way will resemble a Burroughos cut-up, but I shall see. 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.
- lutusp 14y ago
  > 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.
  - keithpeter 14y ago
    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!
jmmcd 14y ago
If the merging isn't also word-aware, then surely this is only half a solution. I don't think the svn script you linked is able to merge (I only read the Readme, no further investigation).
cpeterso 14y ago
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.
- jmuhlich 14y ago
  "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.

keithpeter 14y ago

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 reasonable paragraphs. I think I will try this out as a lot of text editors have line oriented tools. It might be that the result of a lot of rearranging that way will resemble a Burroughos cut-up, but I shall see. 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.

lutusp 14y ago
> 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.
- keithpeter 14y ago
  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!

jmmcd 14y ago

If the merging isn't also word-aware, then surely this is only half a solution. I don't think the svn script you linked is able to merge (I only read the Readme, no further investigation).

cpeterso 14y ago

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.

jmuhlich 14y ago
"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.