Unfortunately, this only counts discrepancy in lines. It's a sort of Levenshtein Distance of lines.

Typically, smart-indenting editors and perltidy can only approximate each other's code (since both are essentially trying to "parse" the syntax, and as we know, only perl can parse Perl). Emacs and perltidy can come close, but don't always agree. I tidy up some foreign code when I get it, then edit from there without re-tidying. So some level of disagreement is quite common.

For a better result, I'd like to see a patch to perltidy where it accumulates a "cost to fix" for each situation it wants to fix. Then you're not post-processing perltidy, but asking perltidy itself: how bad was this sloppy code, quantitatively?

I'd also like a minor mode in emacs where it occasionally executes (perl -c $filename) invisibly, then slightly tints the background of all the lines following the first error found (or better, though I think unsupported, is to tint the relevant fraction of the buffer's scrollbar). You could adjust this to do the same for perltidy... highlighting the first egregious tidy problem.

--
[ e d @ h a l l e y . c c ]