FileCompare please add count of current difference to status-bar

[georgeb]

Since there is a new release-candidate on its way perhaps it's not too late to ask for a really minor addition the absence of which I've found a bit annoying for quite some time now - but I always forgot to issue a suggestion for adding here in the appropriate forum.

Long story short: when comparing 2 files by content the number of differences found thankfully is given in the status bar. Now with the corresponding header-buttons one can jump to the "Next Difference" or "Previous Difference" in a circular manner.

What is not given though is the number/counter of the current difference on display. So please could our cherished Author consider just adding the number/counter of the currently shown difference in the main window to the status-bar? It would be helpful for orientation especially for larger files with many differences found by comparison.

[ghisler(Author)]

Unfortunately the current difference is UNKNOWN. TC counts the differences when comparing, but it doesn't store the location of these differences because these will change when the user edits one of the files.

[georgeb]

Unfortunately the current difference is UNKNOWN. TC counts the differences when comparing, but it doesn't store the location of these differences because these will change when the user edits one of the files.

Thanks for the quick reply. The reasons put forward therein are understood. And yet - since probably 80% of the file-comparisons are done without editing either file - how hard would it be to still add such a counter to the status-bar resulting from the initial comparison only which then would have to disappear as soon as edit-mode is entered? For most cases even such a simple counter would already help a lot.

[petermad]

add such a counter to the status-bar resulting from the initial comparison only which then would have to disappear as soon as edit-mode is entered

Support++

[HalbschuhTouri]

Support +++

[Fla$her]

As far as I understand, the task of TC is to find different files as quickly as possible, which means that it is enough to look for the first different byte to fix the difference and immediately move on to the next pair, so I consider it impractical to count all the differences for each file.

[Usher]

2Fla$her
FileCompare is designed for interactive work. It means that it should be as readable for human eyes as possible. That's why TC displays every difference in full, not limited to the first different bytes.
What is more, TC already counts differences, so keeping the numbers shouldn't take much more time.

[Fla$her]

Beg your pardon. I confused it with the name of another thread and decided that it was about directory synchronization, where you need to show the number of differences for each pair.

[georgeb]

As far as I understand, the task of TC is to find different files as quickly as possible, which means that it is enough to look for the first different byte to fix the difference and immediately move on to the next pair, so I consider it impractical to count all the differences for each file.

But that is what file-comparison currently already does!? Ok, there are the files that turn out to be completely identical. Then all you'll get is a pop-up stating so. But IF there are any differences identified (block-wise, not down to the byte-level) then 2 comparison-windows will come up allowing the user to jump from one different block to the next (cycling forward or backwards by pressing the "Next" or "Previous"-buttons) WHILE AT THE SAME TIME THE STATUS-BAR WILL GIVE THE TOTAL NUMBER OF DIFFERENCES FOUND!

All I'm asking now is as long as no edit-mode is entered - and while cycling through the different blocks identified - this total-count-number in the status-bar should be replaced by a string indicating "currently showing difference 1, 2, 3, ...xx of xx total".. Now this may seem almost irrelevant as long as a total of - say - 4 differences is encountered but it is a total different "ball-game" if xx amounts to 357! If you now start to cycle through them all it would make much of a difference if there are 18 differences remaining to cycle through or 289 - let alone if you've got to make it to a meeting in 40 minutes.

And somehow the number of the current difference-block must already be there as the total number of differences found is already known (and displayed) since the initial comparison-run.

[Fla$her]

2georgeb
Don't you see my next answer above?

[georgeb]

2georgeb
Don't you see my next answer above?

Of course I now do. My answer has already been "in the making" before your correction went online.

[ghisler(Author)]

Here are some examples of why it would be very difficult and time-consuming to implement:
Take two files and compare them. They could have, for example, 10 differences.
1. The user adds some text within an existing difference -> the number of differences doesn't change, but the position of differences after that position changes.
2. The user adds some text outside of an existing difference -> both the number of differences and their positions change
3. The user deletes the text of one of the files -> suddenly we only have one difference
4. The user deletes the text between two differences -> suddenly we have one LESS difference
5. The user deletes text spanning over multiple differences -> we have multiple differences less
etc. etc. etc.

[petermad]

2ghisler(Author)

The suggestion has turned to the possibility of showing the current difference number ONLY if no editing has taken place - is that feasible?

[georgeb]

Here are some examples of why it would be very difficult and time-consuming to implement:
.....
etc. etc. etc.

True, all these difficulties might be hard to overcome and nobody here would demand a tedious major re-work of the whole "Compare-by-content"-process that would need to trigger multiple re-comparison-efforts and slow down the whole process considerably.

BUT ALL OF THE OBSTACLES MENTIONED will only occur ONCE EDIT-MODE IS ENTERED.

On the other hand - and only without edit-mode activated - it should be an easy task when jumping to next or previous differences in a circular manner to refer to the number of the current difference in focus - still resulting from the initial comparison.

Without edit-mode active I currently don't really see these positions-of-difference undergo any change.

So the same way one could argue that the total number of differences found - as currently (thankfully) already indicated in the status-bar - shouldn't actually be shown at all because they would no longer be accurate once the user would apply any changes to the file after entering edit-mode.

Edit-mode - as I see it - is a totally different ball-game. And if the user decides that he must know about the current number of then altered differences nobody would keep him from doing that by making the changes permanent, exiting "Compare-by-content" altogether and re-starting it all over again - which would result in a new comparison showing a valid number of actual differences again.

[ghisler(Author)]

That would indeed be much easier, but people would immediately complain that it doesn't work in edit mode.