Actually the problem has nothing to do with the literal blank line as you suggest, but is in fact an unfortunate result of the padding lines included in the final hunk of the entire Diff. In truth, we had already identified this problem and it is already fixed in the next release, but is pending other unrelated work being completed. In short, if the last hunk contains padding lines, they are unfortunately silently counted on the side where the padding occurs, shifting the trailing line numbers by however many lines of padding occurred in that last hunk.
Nevertheless, we will keep this defect report as active, until such time as we can produce the next release. Thanks for reporting it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you confirm that your description explains the line discrepancy on comparing q.c.old / q.c.new attached? There is no padding, unless you count the odd blank line
Perhaps you're not clear on what I'm calling a "padding" line.
When we read in (then Diff) two individual files, we get hunks of lines that are deemed different. In fact, these hunks describe what to add/remove to effectively turn the Left-side representation into the Right-side one. But when we display those results, we try to arrange those lines that have not changed so that they appear on the same vertical alignment. This can only happen when both the "Left" and "Right" halves of a given hunk has the same number of physical lines displayed. By definition, an "Add" or "Delete" type of hunk has ZERO logical lines on one side, which implies that in order to align the lines that follow the hunk, one side (or the other) needs to be "padded" to contain enough vertical spacing to compensate for the real lines that were designated as Added or Removed on the other side. Change type hunks simply get padded when one side is larger than the other. Note that the content of the real line is immaterial (it could be blank or not); what matters is whether it was a physical line in the original file. The way to visually detect that is to note if the display actually SHOWS a line number for that line or not.
So now we get to view the display and pay special attention to which lines even have numbers presented. When you do that, you can see that for any given "hunk" those numbers are always monotonically increasing (on their given side) ... just as they would be if you were simply viewing the original file content of that given side. But in the TkDiff display, there are those vertical visual gaps (ie. "padding" lines) whenever one side (Left/Right) of a hunk has fewer lines than on the other side IN THAT HUNK.
Next, look at any hunk EXCEPT the last one - Note that the line numbers both preceding and trailing that hunk do in fact run monotonically. If you happen to be looking at a "Change" type of hunk, some intervening numbers will be within the hunk itself, but the values will still run as expected. FINALLY go look at the last hunk. Decide which side of the hunk was padded (by looking for the lack of line numbers on either the Left or Right side). Now compare the value of the first line number FOLLOWING that hunk on that side, to the immediately earlier value on that side and you will see that it is no longer monotonic as it should have been. Instead its as if the padding lines were being counted ANYWAY, despite none of them displaying any such line numbers.
As indicated, this problem ONLY affects the last hunk, and, as such, canONLY cause a problem if that last hunk happens to require the use of "padding" lines. If the final hunk had,
for example, been a Change type where each side of the change referenced exactly the same number of lines, then there would be no observable problem whatsoever. If you want to prove that to yourself, change ONE letter in ONE line in EITHER file that is PAST the lines already being reported (thus creating a NEW last hunk), and all the line numbering will be perfect.
THATs what got fixed. Does that make it any clearer?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Verified against latest download. File a is
and file b is
Despite deleting c, lines d,e &f still show with same line number (screenshot attached)
Actually the problem has nothing to do with the literal blank line as you suggest, but is in fact an unfortunate result of the padding lines included in the final hunk of the entire Diff. In truth, we had already identified this problem and it is already fixed in the next release, but is pending other unrelated work being completed. In short, if the last hunk contains padding lines, they are unfortunately silently counted on the side where the padding occurs, shifting the trailing line numbers by however many lines of padding occurred in that last hunk.
Nevertheless, we will keep this defect report as active, until such time as we can produce the next release. Thanks for reporting it.
Can you confirm that your description explains the line discrepancy on comparing q.c.old / q.c.new attached? There is no padding, unless you count the odd blank line
Last edit: Duncan Roe 2019-05-02
Above is 4.3.5
Perhaps you're not clear on what I'm calling a "padding" line.
When we read in (then Diff) two individual files, we get hunks of lines that are deemed different. In fact, these hunks describe what to add/remove to effectively turn the Left-side representation into the Right-side one. But when we display those results, we try to arrange those lines that have not changed so that they appear on the same vertical alignment. This can only happen when both the "Left" and "Right" halves of a given hunk has the same number of physical lines displayed. By definition, an "Add" or "Delete" type of hunk has ZERO logical lines on one side, which implies that in order to align the lines that follow the hunk, one side (or the other) needs to be "padded" to contain enough vertical spacing to compensate for the real lines that were designated as Added or Removed on the other side. Change type hunks simply get padded when one side is larger than the other. Note that the content of the real line is immaterial (it could be blank or not); what matters is whether it was a physical line in the original file. The way to visually detect that is to note if the display actually SHOWS a line number for that line or not.
So now we get to view the display and pay special attention to which lines even have numbers presented. When you do that, you can see that for any given "hunk" those numbers are always monotonically increasing (on their given side) ... just as they would be if you were simply viewing the original file content of that given side. But in the TkDiff display, there are those vertical visual gaps (ie. "padding" lines) whenever one side (Left/Right) of a hunk has fewer lines than on the other side IN THAT HUNK.
Next, look at any hunk EXCEPT the last one - Note that the line numbers both preceding and trailing that hunk do in fact run monotonically. If you happen to be looking at a "Change" type of hunk, some intervening numbers will be within the hunk itself, but the values will still run as expected. FINALLY go look at the last hunk. Decide which side of the hunk was padded (by looking for the lack of line numbers on either the Left or Right side). Now compare the value of the first line number FOLLOWING that hunk on that side, to the immediately earlier value on that side and you will see that it is no longer monotonic as it should have been. Instead its as if the padding lines were being counted ANYWAY, despite none of them displaying any such line numbers.
As indicated, this problem ONLY affects the last hunk, and, as such, canONLY cause a problem if that last hunk happens to require the use of "padding" lines. If the final hunk had,
for example, been a Change type where each side of the change referenced exactly the same number of lines, then there would be no observable problem whatsoever. If you want to prove that to yourself, change ONE letter in ONE line in EITHER file that is PAST the lines already being reported (thus creating a NEW last hunk), and all the line numbering will be perfect.
THATs what got fixed. Does that make it any clearer?
Thanks Michael - all clear now
As discussed, repair is in new release V 5.0