The suggested edit view just showed me two drastically different views of content based on whether I was looking at the rendered mode or the markdown mode:
First, the rendered diff view, showing a lot of code changed:
Second, the markdown diff view, showing nearly nothing changed:
I believe this is a bug. The rendered-diff is difficult and doesn't need to be perfect -- but this one was way wrong. :)
tl;dr: Fixed in the next build.
The problem here is that we have to be a bit defensive when diffing huge posts, in particular, huge codeblocks.
Our diff engine is based on this implementation of Eugene Myers' O(ND) difference algorithm. The N in this case stands for the length of the text; the D stands for the number of edits. In the usual case, this results in great diff performance.
Assuming you just fix a typo (so maybe D=2), the performance is linear in the text length. In other words, fixing a typo in a 2000-word text results in a diff that text takes 40 times as long as the diff for fixing a typo in a 50-word text. That's fine.
If, on the other hand, you change not just a typo, but the whole text, this means D=N and hence O(N²) performance – so between a 50-word post and a 2000-word post, the difference is suddenly 1600-fold.
A few weeks ago, this became painfully obvious in this suggested edit. The Markdown diff here is no problem (just insert spaces en masse, but leave the rest as-is), but the diff of the rendered version compares two pretty much unrelated walls-of-code (since a code span is entirely different from a code block). Creating that diff took 35-40 seconds, which is obviously not tolerable.
Chances of this issue appearing are much higher for code blocks than for normal text, because a) they have a higher tendency to be huge, and b) when tokenizing code blocks for diffing, the tokens are usually smaller (and thus come in greater numbers) than for normal text, since codeblocks need higher accuracy (e.g. for whitespace).
Unfortunately, you will of course never know the value of D until you actually run the diff, so in order to make sure that the diff runs in reasonable time1, we have to be defensive here and assume the worst case, which is D=N.
So we added a two-step diffing process for long posts. If the number of diff tokens is above a certain threshold, we first put them into groups (essentialy grouping them by their position in the DOM), and only compare the groups as a whole. Only then are the contents of two differing neighboring groups compared. So if you fix one typo in a 50-paragraph text, 49 of the paragraphs are identical and don't have to be compared word-for-word.
This is where your case comes in: Making a minor change in a huge codeblock. We don't want to diff the two versions of the codeblock word-for-word, since they may be entirely different, in which case you can get yourself a coffee before the diffing is done. On the other hand, we also don't want to make it seem that the entire code block has changed, which is what it looked like to you, although it really hasn't.
So I've added yet another step: Before bailing out ("too huge to diff; just assume the entire thing has changed") we try yet another step: A line-by-line diff. We don't touch unchanged lines, and only compare differing lines word-for-word.
In certain cases, that may still cause a change in a huge codeblock to have a less-finegrained diff than the same change in a smaller codeblock, but in most cases (in particular, the one you found), we can now create a reasonable diff of a large code block without running the risk of melting our server CPUs.
1 This would obviously be a DOS vector. Had someone posted that "suggested edit of doom" to Reddit before we fixed this, our servers would very certainly have come to a screeching halt.
