You've got mixed tab and space indents (server_side_selection); inconsistent spacing style in new code; inconsistent spacing style even within a space-only change (roman); a bulk reindent mixed with content change making the latter harder to follow (default_options); poor factoring (that sprintf paste table in highlight_as_diff, not to mention assigning a variable just in order to return it).

Then there's the angle that since it's 406 lines of patching on what was a 346 line file it might as well be a total rewrite, from which view it's a missed opportunity to fix the overall structure. Such as dropping the "plugin" baggage wherein this (and only this) file is considered "content", on a level with themes and uploads, despite in actual usage being part of the core text formatting, on a level with the insertion of br and p tags; and wherein the "how to deploy a new blog" process that nobody's published except in bits and pieces needs to include "don't forget to activate the footnotes plugin!" in its lengthy list of ridiculous GUI-based post-install tasks. Or the "Encapsulate in a class [for no discernible reason and requiring more code to instantiate it into a throwaway global variable]".

so it will work across all themes without modification

Except that existing users already put selection code in their own themes per the original recipe so... won't the two implementations interfere unless the old one is manually reverted in full or in part?

There was a fix I made earlier on my live version that breaks the long file hash in a vdiff but for the rest of the code only wraps at the word level. I forgot to carry this fix over when updating the patch.

A wider layout for displaying code will help readability as well (just so that less wrapping is required in the first place). I'm working on an update to my theme that will improve this.

So what can we do, sit here like savages, "your thing runs offscreen".