Small wishes for Compare by content tool

[browny]

I'll just drop several vague ideas and maybe some of that would be found interesting.

1) It might be nice to have the difference number (index in the list) to be displayed.
Or maybe even an entry field with direct jump by difference number.
I do not expect that this index would be tracked when user randomly moves around; only on go to next/previous difference commands.

2) Another "vertical" positioning helper: colour stripes which mark differences in scrollbar or nearby. It seems to be a stock feature of modern diff tools (though the idea existed in times of ancient Windiff program, if not before).
Edit. There are two vertical scroll bars. It both move synchronously, then one could be replaced with graphic representation of differences.

3) Done two lines are displayed at the bottom.
There is already a topic in Suggestions about highlighting found text (with yellow marker-like background). While I agree with that, I also think that similar background highlighting (with different hue, naturally) might be a great help in ordinary difference display.
It is quite a chanllenge to find a single-character difference - dot or comma (let alone space) in a line, especially when a lot of horizontal scrolling is involved.

4) Done, Alt+Left/Alt+Right for fast horizontal scroll.
Speaking of horizontal scrolling - it is too slow with keyboard, and mouse clicks on a scrollbar is an inconvenient method in most cases.
Could Ctrl-Left/Right combinations be added to scroll by wider steps?
Step might be measured in character width or in (fraction of) panel width.
Edit.After a while I understood that we are using PgUp/PgDown without major problems, and so scrolling horizontally by full width of panel would be good.

[petermad]

Good suggestions, thohg I dont know what 2) really does. Support++

[MVV]

petermad,
I think 2) is a comparison map that shows where files are different or equal. You can google for images using windiff term to see how it looks in different comparers.

[petermad]

I think 2) is a comparison map that shows where files are different or equal. You can google for images using windiff term to see how it looks in different comparers

I see - that does not look like a small wish. But the 3 others look like they are relatively easy to implement, especially 4)

[MVV]

That's correct, 2) is not a small wish.

[browny]

Let me explan about that windiff subject.

That was just a prototype idea; I do not ask for reimplementation of windiff - even though its source code is available and its comparison algorithm sometimes works better than TC's. Also I do not need maps for both files (let alone those lines connecting equal blocks - very fancy, but also useless).

It you saw how recent Visual Studios mark on the right side (between editor's pane and scrollbar) things like changed lines, errors or found text, then you would have much better understanding of my idea. Or if you know VS built-in diff tool. If file is long and proportional marking might get too narrow, then a small colour "brick" would be painted - still a good clue.

What I suggest is just colour markings where the files differ. Perhaps not in the scrollbar itself, but rather in a separate narrow "map" strip nearby.
When TC compares two files, it makes virtual panels of the same vertical length, and that length is represented as the scrollbar's length.
Now paint the "map" with standard background where lines are equal and red where lines differ.
Does it look complex?

[MVV]

Visible window should also be drawn on the map, e.g. with different background.

I think that in case of editing modified lines may also be marked...

[browny]

Visible window should also be drawn on the map, e.g. with different background.

That usually is reperesented with a thumb on a scrollbar.

I think that in case of editing modified lines may also be marked...

A few things could be marked simultaneously, but let's see if the author would like these ideas.

[MVV]

That usually is reperesented with a thumb on a scrollbar.

Thumb height doesn't reflect visible window size (it would be too tiny in case of very large files) so window size may be different. E.g. Visual Studio shows visible window with different background.

[browny]

Thumb height doesn't reflect visible window size

It does reflect in some implementations; just take a second look at TC's Compare by contents window.
Obviously, the thumb size should not drop below reasonable limit.

(it would be too tiny in case of very large files)

... and so would be background markings.

E.g. Visual Studio shows visible window with different background

Your picture shows extension or some other tool, not built-in development environment code editor.
Here you can get detailed description.
I must say that this feature is extremely convenient in VS.

[MVV]

... and so would be background markings.

And it is correct because visible window will be too small.

Your picture shows extension or some other tool

You're right. Anyway, I've just tried opening 180MB file in VS2015 and noticed that thumb is too small... however I don't believe that too much people will edit such text files in VS, while TC should be prepared for huge files.

[browny]

Points 3 and 4 were implemented, thanks. The first post was updated accordingly.
The only issue with point 3 is that white space is invisible (especially when trailing whitespace is the only difference), otherwise it was very helpful.

Can other points be discussed and/or become candidates for implementation?