11

I made a few spacing edits to a question, changing some lines with 8 leading spaces into 4 leading spaces.

So why does the question's revision history say that, instead of removing 4 spaces, I removed 5 spaces and added 1? This is rather nonsensical at best and outright confusing at worst. Why can't it just display a removal of 4 spaces?

1
  • 7
    I don't know how diffs actually work under the hood but I imagine that it uses a lexer and clumps certain characters together into a single group (the spaces) and treats and changes among them as one. It saw a group of 5 spaces and saw you changed it to a "group" of 1 space. If you're familiar with compiler theory at all, you'll know that handling all possible corner cases like this is not a trivial thing to do. I suspect whoever coded it went for simplicity over getting every corner case perfect. This is just not an important issue either, it's not wrong that it is interpreted this way. Nov 7, 2011 at 19:12

1 Answer 1

18

For the most part, Jeff Mercado's comment on your question is correct; not everything in the diff will always make the most sense to a human in all edge cases.

For example, if you fix a typo to turn "wheather" into "weather", you're just removing a single letter – however, the diff will show that you removed one word and added another. While in that case, to a human it may actually be more obvious to just show a single removed letter, in many cases doing a character-by-character diff would just make things worse:

   char diff

So that's why we're doing word-by-word diff. Not only that; we're also considering trailing spaces part of the word; otherwise, you'd have this:

   word diff

But in most cases, the most readable diff is actually this:

   word diff including trailing spaces

– and the "most cases" thing is obviously what we're optimizing for.

That said, I've made some improvements to the whitespace handling in the diffs. One thing you noticed was even an actual bug: The reason that you seemed to be inserting one space and removing five was the fact that under certain circumstances, breaking the text into tokens for diffing created empty tokens, causing a a "nothing" was removed here, and a "nothing" was added there diff.

Since a "nothing" is invisible, and we're replacing invisible changes by a space (saying "you can't see it, but something changed here), this caused the 5/1 instead of 4/0 diff you observed.

Both this bugfix and the whitespace improvements will be in the next build.

4
  • Not that this is necessarily worth it, but there is (I think) a relatively simple way to detect most useful one or two letter changes like 'wheather' to 'weather'. In the majority of cases, this is a spelling correction, in which case it would be possible to simply check if the new word is a spelling correction for the previous one, and if the previous one was misspelled. Again, not that that would be worth it. May 17, 2012 at 5:00
  • @balpha, Since there's no general purpose diff, Shouldn't the diff be context-based? For example, in a code section we would do line-by-line-diff, whereas in normal paragraphs, we would do english-diff.
    – Pacerier
    Mar 25, 2015 at 15:43
  • 1
    @Pacerier Code diffs and text diffs already are different.
    – balpha StaffMod
    Mar 25, 2015 at 16:14
  • @balpha, Are the algorithms in-house? Which algorithm did you use for the code diff?
    – Pacerier
    Mar 29, 2015 at 2:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .