Menu
▾
▴
3 Attachments
#60 tkdiff shows erroneous deletion when using diff -bwB
tkdiff is showing a deletion where there is none (and diff -bwB shows none). Sample files to generate this and resulting screenhshot attached. Note that I was using 4.0.2 (on Linux 2.6.9-67.0.1) at the time but I'm sure I got he same thing on 4.2.
Yep. That is EXACTLY what V4.2 (and earlier) will do. It was addressed in V4.3.1, but I'd recommend getting the latest TkDiff release possible to avoid simply trading up to newer problems.
The issue was that earlier versions were never designed to handle the Diff options that ignore entire LINES (such as Blank or Regular expression matched ). Those options existed (at that time) solely for use by Diff alone - despite it being possible to pass via TkDiff.
The newer versions of TkDiff should handle them just fine; and in fact, they are now handled as independently configurable user settings. Time to trade-up.
Bug report being closed as "already" fixed.
We're (at work) only just about to trade up to 4.2, alas. We work on old OSes and s/w because that's what our customers still use, because they require ultra-stable systems. Sad but true. Regardless, on first impressions my private 4.3.5 still gets it wrong (although differently wrong). See new screenshot. Perhaps I need to look at the user settings.
Update: the only other user setting that I could see was "ignore blank lines" and that made no difference.
And FYI:
diff (GNU diffutils) 3.3
Tk version 8.5.13
Last edit: Marky Mark 2018-12-21
Interesting - ever since I joined TkDiff I have been amazed at the slow but continual downloads of the truly old versions. Nevertheless, I can gaurantee that those earlier versions will NEVER correctly process the use of the -B Diff option. One of the basic assumptions by the code is that any changes in line counts can only occur within the bounds of a diff-hunk. By using the -B option, you are telling Diff to suppress what is an actual difference which TkDiff then never sees , thereby shifting that line count. Thus the relationship between the numbers within subsequent hunk diff-headers now INCLUDES any cummulative "extra" blank lines that TkDiff should have compensated for by injecting an equivalent number of DISPLAY blank lines into the opposite side to keep them aligned (and would have if it had seen it). Thus any markings added by TkDiff beyond that point end up attached to the wrong physical line of the file that didn't have the extra lines.
If you are not seeing the correct behavior from V4.3.1 (or higher) perhaps it is because you are still trying to pass the -B option via your user settings - this is why it became its OWN specific setting in the newer versions (the one you mentioned you saw)! TkDiff itself does the requested suppression in response to that setting and never passes the option to Diff. This has the added advantage of being usable with other differencing engines (where -B might not even be understood). There is a fairly lengthy explanation of this in the online help available within the newer versions under the "On commandline" grouping (near the end).
You stated that the version of TK you are using is Tk8.5.13 which is perfectly acceptable to TkDiff 4.3.5, as TK >= 8.5 is the single pacing requirement for versions TkDiff4.3 and beyond. You further mentioned that this "super stable" issue was a work-related requirement, yet I guess I dont understand why the latest possible tool that would function within such an environment would be off limits...why use outdated tools when working? There are an awful lot of bug fixes, besides the new features, since the versions that actually worked properly with TK8.4 (like since a decade or so ago). I know; I fixed a BUNCH of them.
It's ok, I don't for a moment expect anyone to try to fix bugs in old verions. I'm as frustrated by having to use 4.0.2 as you seem to be at getting bug reports for it. I entirely take your point about the newest tkdiff version clearly working in the being-migrated-to environment (Tk 8.5 and all) so I will see if I can find out who gets to decide when we should upgrade tkdiff.
Still I am rather surprised that tkdiff is written to do anything other than interpret the diff output, which produces something perfectly sane-looking with or without the -B. In a former Motif-centric existence I used something that was precisely written solely to take the diff output and turn it into something graphical, but there you go, there are always several ways to approach any problem.
I though I had tried the various combinations of diff arguments and tkdiff options to no avail, but I will try again. For now though I'm not back at work again until the New Year so I will pick this up when I can. Meanwhile thanks for your comprehensive response and have yourself an appropriately festive/cheerful/celebratory time.
Back at work and I've found one minor and one major issue with this for which I've opened new tickets.