File compare - jump to difference

[ghisler(Author)]

You can turn off the bottom two lines if you don't need them. I still find them useful for files with reasonably long lines where you can see the entire two lines at one glance and spot the differences above each other.

[georgeb]

...the truth is, since the [F2]/Shift+[F2] module exists, the bottom two-line window isn't even necessary anymore.
..
Now what the two-line window was supposed to address has been successfully replaced by the new [F2]/Shift+[F2] functionality.
..
So just turn off the bottom two-line window. It's superfluous.

While this point of view is basically correct I dare to not entirely agree. As the 2-line-window positions the differences currently in focus directly above each other - in addition to side-by-side view - this facilitates the identification of (multiple) single-character-differences in otherwise mostly congruent texts by emphasizing those at a single glance and in synchronized fashion above each other.

As for the <F2>-mechanism rendering the 2-line-window otherwise obsolete I would completely agree - if - and only if - the jump to the actual next character-difference (as opposed to the current jump-to-the-next-line-with-an-undetermined-number-of-differences) became standard behavior also in normal viewing-mode without having to apply edit-mode first.

This is in my view the basic (logical) inconsistency here. I would have to acknowledge all the differences first while still inspecting the file in viewing mode - and without running a high risk of overlooking some outside the current field of view - before I can decide if at all and where exactly some editing might become necessary.

[JOUBE]

As for the <F2>-mechanism rendering the 2-line-window otherwise obsolete I would completely agree - if - and only if - the jump to the actual next character-difference (as opposed to the current jump-to-the-next-line-with-an-undetermined-number-of-differences) became standard behavior also in normal viewing-mode without having to apply edit-mode first.

Without going into the other elements of your post (which can be discussed): it is wrong (if I understand you correctly) that only the first difference in a line is jumped to and then the next line is jumped to: all differences in the line are always jumped to - one after the other - and only then jump to the next line. F2 can also be run in 3 different modes. Please try what suits you best (CompareF2Mode=0/1/2).

JOUBE

[georgeb]

it is wrong (if I understand you correctly) that only the first difference in a line is jumped to and then the next line is jumped to: all differences in the line are always jumped to - one after the other - and only then jump to the next line. F2 can also be run in 3 different modes. Please try what suits you best (CompareF2Mode=0/1/2).

I'm afraid you misunderstood. And therefore I hold that what I described is correct, the actual situation being even worse than that.

I was referring to the <Next Difference>-button in standard viewing mode which is the core-element for each comparison. So to give you some palpable example to consider for this discussion I've been comparing a large .txt-mode-table as of recently. Pressing <Next Difference>-button once jumped to line 4 which at first glance seemed to be void of any differences. No difference had actually directly been jumped to at all.

Only on closer inspection with scrolling to the right manually I found out that line 4 actually contained 2 differences, both of them far outside the initial field of view, both of them invisible in the 2-line-comparison-window as well.

Now pressing <Next Difference>-button again jumped directly to line number 9, where one difference was directly visible (b/c not far out in that line). So it would be fair to assume that this was the 2nd actual difference.

But wait a minute! Line-4-to-9 were (color-wise) marked as one block with differences while line No.10 was indicated as the next truly congruent line.

Out of curiosity I then started an outside dedicated comparison tool and guess what? It turned up a total of 23 differences within that interval from line-4-to-9 alone which had altogether been missed by the <Next Difference>-button!

I then went back to TC-compare-module and now turned on edit-mode. The <F2>-mechanism then correctly jumped from one difference to the next - as it should be - but only via the <F2>-button with edit mode active.

My point now is that this <F2>-mechanism - from a logical point of view - needs to become the primary-mode/standard-behavior for the <Next Difference>-button by uncoupling it from editing mode and the need for an active cursor altogether!

Because right from the start I cannot know if and how many differences will be found in there and if - as a consequence - the need might arise to edit/correct some or all of them.

The whole purpose of the file-comparison is to find out about the occurring differences FIRST and with this information THEN being able to decide if and where editing would become necessary.

But how useful is such an initial/basic comparison altogether if its standard <Next Difference>-button-mechanism misses out on might 22 of the actual 23 differences - alone within the short interval from line-4-to-9 in my example-table?

Of course, once you know about this deficiency you can apply an easy workaround by always comparing in edit-mode from the start and using <F2> all the time instead of the standard <Next Difference>-button. And therefore I explicitly applaud the author for implementing this new feature in the latest TC-makeover, so don't get me wrong here.

But as I'm afraid many 08/15-users of TC won't be aware of this deficiency of the basic <Next Difference>-button and so kind of some bitter aftertaste remains that the basic comparison-mechanism via the <Next Difference>-button might easily miss out - at least prima-vista - on quite a few differences and so leave the false impression that everything is in-sync.

If I press a button that says "Next Difference" I now would legitimately expect that button to reliably jump from one difference found directly to the next (in-line or otherwise) - it's as simple as that!

[petermad]

2georgeb

Well if you read the Help, the behaviour should be no surprise to you:

Next difference
Jumps to the next difference found. A continuous block of different lines will be regarded as ONE difference.

And that is extremely conveniant, especially in Edit mode, because the whole block gets selected, ready to be copyied to the other side - or deleted.

[georgeb]

Well if you read the Help, the behaviour should be no surprise to you:
...
And that is extremely conveniant, especially in Edit mode

Never said that I've been "surprised" by that behavior. My argument made was that such behavior is insufficient for an effective and professional comparison-tool.

As for that mode being "extremely convenient" - well, it seems the jury is out on this. I would completely agree if "help said":

Jumps to the next difference found. A continuous block of entirely different lines will be regarded as ONE difference

But in my example given above those lines are 98% congruent and the emphasis lies on isolated byte-/character-wise differences. So how would this behavior be "extremely convenient" for editing if I am completely left in the dark about 22 out of 23 total differences to begin with?

A mandatory premise for effective editing would be to know about ALL the differences and about the correct/changed variants thereof in the first place!

[ghisler(Author)]

The "Next difference" button is separate from the F2 function. It is meant to jump to the next block of different lines. F2 is meant to jump to the next difference within a line, which could well be hundreds of differences in a single line.

[georgeb]

The "Next difference" button is separate from the F2 function. It is meant to jump to the next block of different lines. F2 is meant to jump to the next difference within a line, which could well be hundreds of differences in a single line.

Understood. So an important first step into the right direction of finding a remedy for the problem I've described above in my example would be to make the <F2>-functionality globally available also in basic viewing-mode-comparison without the need for a cursor or having to enter edit-mode before.

The reason for that - as I have already mentioned before - being that you need to know about any/all-of-the differences byte-wise/character-by-character first (through an initial comparison-run) and only then can decide if and how editing of one/both variant(s) might become necessary.

Perhaps it then would make sense to split the Next-/Previous-buttons into two halves each
"<Jump_Block_Diff>/<Jump_Character_Diff>"
- but I personally could live with <F2>/<Shift>-<F2> as well - as long as these options would become available in basic viewing-comparison and outside edit-mode also.

Another minor but nice addition to have would be to allow for inverted color-representation for different characters/bytes (the actual differences found) within (partly) different lines or blocks. This would be more of an eye-catcher as currently only enabling a different front-color on the identical (different-line-)-background.

[JOUBE]

...behavior is insufficient for an effective and professional comparison-tool.

The opposite is true.

- The TC is a file manager and the comparison tool should also be seen in this context. It is intended to give a quick overview of whether there are differences between files. This is extremely useful for professionals, because it also gives an _overview_ of whether and what differences there are, for example, in configuration files, source code files and scripts/batches. I need that x times every day. These files also tend to have fairly short lines so that when you jump from difference block to difference block you can see the differences highlighted in red. There are also such specialties as skipping multiple spaces, etc. part of the tool.

So you can quickly and easily clarify within the file manager whether there are differences and how extensive they are. Or whether files differ only in terms of date and not at all (or only in terms of spaces/lines, etc.). A tool for professionals.

This addresses also the quick and easy copying/re-copying/overwriting of blocks with differences.

If one sees from this first overview that there are major differences, one will use a tool appropriate to the matter. An IDE, an editor, a special program...

Only with version 10.50 has a small fine extension been added. You can now take a closer look, especially when the lines are longer: F2/Shift+F2. This does exactly what it's supposed to do, look at each difference individually and assess how best to deal with the differences: change directly or go to an IDE, an editor, a special program...


- By adding F2/Shift+F2 functionality there is now a semantic problem only (for beginners at the first day of use ):

Simply edit your language file (Wcmd_xxx.lng):

1314="%i difference(s) found"
6203="&Next difference"
6204="&Previous difference"

becomes:

1314="%i block(s) with differences found"
6203="&Next block with diffs."
6204="&Previous block with diffs."


- The good thing about TC is that you can embed your favorite merge tool instead and/or embed one or even more in the menu or button bar.

JOUBE

[georgeb]

The opposite is true.

Doesn't sound as if you had considered my example for even one minute.

- The TC is a file manager and the comparison tool should also be seen in this context. It is intended to give a quick overview of whether there are differences between files. This is extremely useful for professionals, because it also gives an _overview_ of whether and what differences there are, for example, in configuration files, source code files and scripts/batches. I need that x times every day. These files also tend to have fairly short lines so that when you jump from difference block to difference block you can see the differences highlighted in red.

Point taken. I need that functionality a dozen times a day as well and are really glad it is there. So we can fully agree that TC offers an efficient "Short-Line-Files-Comparison-Tool".

So you can quickly and easily clarify within the file manager whether there are differences and how extensive they are.

Nope! With files containing extra-long lines you really can't say anything about the actual scope of differences by mere comparison! Other than asserting if two files happen to be identical or not (this although being quite an important basic functionality even offered by TC_Android) one cannot make a qualified statement, not even an educated guess about the true scope of differences as the mere count of different blocks is almost meaningless.

This addresses also the quick and easy copying/re-copying/overwriting of blocks with differences.

Nope. How could you even make an educated guess about the necessity of overwriting/editing whole blocks if you haven't seen even a fraction of the possible differences contained therein?

Only with version 10.50 has a small fine extension been added. You can now take a closer look, especially when the lines are longer: F2/Shift+F2. This does exactly what it's supposed to do

True and well appreciated, but unfortunately only in edit-mode - the necessity of which to enter can only reasonably be determined after receiving comprehensive information about the actual scope of differences.!

- By adding F2/Shift+F2 functionality there is now a semantic problem only (for beginners at the first day of use ):
Simply edit your language file (Wcmd_xxx.lng):
1314="%i block(s) with differences found"
6203="&Next block with diffs."
6204="&Previous block with diffs."

Boy! If you really think embellishing the verbiage here would make any of the real problems I've described in this thread go away - I'm afraid I'm not the person either to convince you with further arguments of an obvious situation you seemingly refuse to comprehend.