#12 Comparison showing moved blocks of code
Many years ago, I fell in love with an OS2 application
called GFC, for Grapical File Compare. It had a
feature I still haven't found an alternative for on
other platforms, where instead of showing a colorbar
representing the lines that were different between the
two files (like the current tkdiff), it would show two
colorbars, one for each file, and it had a way of
detecting text blocks that were the same and would draw
a line connecting a block in each of the two colorbars
if that block had moved within the file. If this were
added to tkdiff, it would be fantastic.
For example, if a file contained function 1, function
2, function 3 in order, and was compared with a file of
the same source, but where function 3 had been moved to
be before function 2, it would color code the blocks
and show an attachment between the color bars that they
were actually the same code, and had only moved within
the file.
It wasn't specific to functions though, it would work
with any lines that were identical but in a different
place. And it would even work if all of the moved
lines in a block weren't exactly identical, as long as
they were similar enough.
One thing that GFC didn't have was an option for
setting the "similarity weight" so you could control
how aggressive it was about finding what it considered
to be matching lines/blocks, but that would be a cool
thing to have added to tkdiff as well.
Logged In: NO
I think that would require quite a tkdiff rewrite. As I
understand it, tkdiff is really just a graphical front end
for the diff program. A feature like this would require a
new diffing engine and would turn tkdiff into much more than
just a front end.
"Nobody" (from the above post) is correct. TkDiff is somewhat constrained by the limits of what "Diff" will return as data, and what Tcl/Tk provides in both ability and power. While it is possible to use something other than Diff with TkDiff, I know of no existing engine that identifies (reliably) moved code blocks. Add to that all the things that could happen when drawing lines between arbitrarily positioned blocks, and you end up with a bi-partite graphing problem that is well beyond the original intent of a "graphical Diff frontend", while simultaneously pushing the throughput boundaries of the implementation language. Maybe someday, but I wouldn't hold my breath. However, these days there are other candidates that might fit your desires - its all in what you value most.