16

When I see an edit that adds backtick formatting like this, the formatted view shows a lot more changed text than is actually the case. Specifically, whitespace before the opening backtick and the entire word after the whitespace after the closing backtick are highlighted, despite being in no way modified. Highlighting the enclosed text is fine, but this goes too far and is rather unhelpful.

Markdown view is sort of OK, but sometimes I want to see a more concise view without all the unchanged lines, or to see the end format more clearly.

Improve this question
4
  • I think read at some point a valid reason for this, but cannot remember what/where. Switching to markdown often shows a clearer view of edits. – James May 9 '15 at 4:36
  • @James: Okay. Clarified why Markdown view is not always good enough. – Nathan Tuggy May 9 '15 at 4:38
  • @James You're probably thinking of meta.stackexchange.com/questions/166923/… – balpha Jun 9 '15 at 11:11
  • @balpha Ahh yes, cheers. That was it – James Jun 9 '15 at 12:41
17

TL;DR: Fixed in the next build.

I've made two changes to the diff engine, so once this is deployed it'll look as expected. For reference, this is what you saw and complained about:

screenshot of the diff that's linked in the question, before the bug fix

And this is what looks like after my changes:

screenshot of the same diff, after the bug fix

(I've removed the unchanged codeblock from the screenshots.)

The two changes I've made are as follows. First, when separating the text into diff tokens, we no longer consider trailing spaces to be part of HTML tags. This never made a lot of sense, but even less so after this change. The consequence it had was that when, say, bolding a word from

This is very important.

to

This is <b>very</b> important.

then in the first version, important has a leading space, and in the second version it doesn't (the space after the </b> would be considered part of the tag instead). That's why the word "important" was shown as changed.

The second change I made also has to do with the space-as-part-of-the-word thing. For some background why that's necessary I again refer you to this answer of mine, but the short story is that because we don't want this:

   

until 2013 we got this:

   

and from then on we did this:

   

The leading space being added and removed still looked a bit weird, especially in the side-by-side view:

   

So I've added a post-processing step. After the diff engine has run, we look for a space that appears at the beginning of both a removal and an insertion that occur in the same place, and mark that space as unchanged instead.

And with that, what we'll get from now on is this:

   

Improve this answer

You must log in to answer this question.

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