Why would editors need this? Editors look after good or bad edits, but these different types of "complex" diffs cannot make such distinction. Besides, it would take a lot of extra space in the history.

I believe this is a wontfix.

This is a very reasonable request (now that I extracted its spirit and actionable item), however it's going to be rather hard. I think edit distance would be the easiest, but it would still require a schema change.

Other possibilities could be:

• visual diff percentage (there is some on/off experimentation in this area),
• HTML output bytecount difference/edit distance.

AbuseFilter already has such things (added/removed lines, old vs. new html); maybe one of these could be added there for a start (for the anti-vandalism side).

In T10571#130430, @Qgil wrote:

Why would editors need this? Editors look after good or bad edits, but these different types of "complex" diffs cannot make such distinction. Besides, it would take a lot of extra space in the history.

I believe this is a wontfix.

I know I'm replying to a very old comment, but editors need this to see if anything's actually changed on the page. If I see a page with two edits and a bytecount change of 0, that could either be vandalism that's already been reverted, in which case I can ignore it, or it could be two separate edits that resulted in an article of the same length, in which case I would need to check to see if it's a good edit or a bad edit.

That would be so much more informative!

The byte size difference doesn't tell you much about an edit in most day-to-day work. A few changed bytes, for example, may indicate either typo fixes or a fundamental rewrite of the lede. Displaying the edit distance isn't going to be a silver bullet but it would be a massive improvement.