File compare - jump to difference

[georgeb]

There was a new feature announced for File-Compare that I find very useful. When you've got text-files that have much content arranged in (very) long lines without CR/LF or hard-wrap it is now possible to jump to the next difference via <F2> button even within a line and not being forced on an expedition via horizontal scroll to identify those.

However in the bottom window called "two line list" IIRC there seems to be no synchronized jump to the next difference found via <F2>. This seemingly remains static and can only be scrolled manually in horizontal direction.

Two questions:

1. Is that on purpose - or shouldn't that window jump to the next in-line-difference via <F2> in a synchronized fashion as well?

2. Is it true that this whole in-line-jump-to-next-difference-feature only works in edit-mode? And if so - why is that? Wouldn't this be a desirable feature in read-only mode as well? There are text-files out there formatted with epic (single) line-length which have indeed been cumbersome to inspect for differences so far. Or did I get something wrong here?

Is there perhaps a "hidden" feature (or only unknown to me) that would allow for a "virtual-line-wrap"-display of such epic single-lines that would break them down to wrapped-to-window-size-multiple-lines virtually so that horizontal scrolling could be avoided altogether while still keeping the whole content, together with all differences found, visible within the given windows all the time?

As I see it this could be somewhat problematic because of constant re-wrapping of virtual lines with changing window-sizes - but at least in full-screen-mode (which I exclusively use for such purposes) this would be an elegant solution for the long-lines-differences-problem without causing any additional re-wrapping at all.

[petermad]

I support that F2 should also scroll the two-line-list - maybe optional or maybe when using Shift+F2.
I also agree that it would be nice if F2 also worked in non-edit mode.

But I think that virtual-line-wrap would be confusing and difficult to implement so it would seamlessly work with all possible combinations of font size and font family, DPI-scaling and different screen resolutions on for example multi-screen systems

[ghisler(Author)]

1. Yes, because F2 is for positioning the cursor at the start of the next difference within a line. You cannot show the cursor in the two line compare window at the bottom: it would need two cursors, which isn't supported by Windows.
2. Yes, that's the whole point of the function: Jump to the next in-line difference, e.g. to edit it. Also you wouldn't know where the next difference is without the cursor, e.g. when only spaces were added.

Is there perhaps a "hidden" feature (or only unknown to me) that would allow for a "virtual-line-wrap"-display of such epic single-lines that would break them down to wrapped-to-window-size-multiple-lines virtually so that horizontal scrolling could be avoided altogether while still keeping the whole content, together with all differences found, visible within the given windows all the time?

If your files are xml, use an xml beautifier: these are programs which add line breaks and spaces to make xml files human readable. After doing this, the comparison will be much easier, and the xml files still work.

[petermad]

2ghisler(Author)

1. Yes, because F2 is for positioning the cursor at the start of the next difference within a line. You cannot show the cursor in the two line compare window at the bottom: it would need two cursors, which isn't supported by Windows.

Would it be possible to scroll the the two line compare window, so that the middle of the window shows the position of the F2-cursor in the main panel?

[georgeb]

2. Yes, that's the whole point of the function: Jump to the next in-line difference, e.g. to edit it. Also you wouldn't know where the next difference is without the cursor, e.g. when only spaces were added.

Ok, understood. But as I see it the feature in question wouldn't require any cursor at all. Because the differences found are already highlighted by different colors (hopefully wisely chosen). The only problem is that with (very) long lines or large tables those highlighted differences are possibly far outside the field of view and therefore hard to identify.

So jumping directly to them, one by one - or in other words jumping truly and directly to the next difference found (as the button indicates) and not only jump to the line containing the next differences (as it actually currently does) - would remedy the entire problem without using any cursor at all and would therefore also work in simple viewing mode without activating edit mode.

To enhance the visibility of those "to the group-of-letters-accurate" differences within the current "jump-to"-focus even more - these could be once more "super-emphasized" by applying yet another (inverted?, yellow-on-red?) color-combination.

And all that in standard viewing mode, without activating "edit" altogether. There would even be no need for <F2>, just the "Next-Difference"-button would suffice if "elevated" from the current "Next-line-with-differences"-functionality.

If your files are xml, use an xml beautifier: these are programs which add line breaks and spaces to make xml files human readable. After doing this, the comparison will be much easier, and the xml files still work.

No, they unfortunately happen to be ordinary .txt-files, including large tables. So such a beautifier wouldn't help, I'm afraid. Also there are large tables in .odt-format - but comparing those outside of LibreOffice is yet another problem.

[georgeb]

Would it be possible to scroll the the two line compare window, so that the middle of the window shows the position of the F2-cursor in the main panel?

In layman's terms (and without any desire to interfere with the competence of the author) I can see no obstacle that would prohibit such functionality. In particular if (as I wrote to ghisler(Author) above) the whole "Jump-to-next-difference"-mechanism could be de-coupled from edit-mode and the corresponding need for two cursors there.

Also positioning the current difference into the middle of the two-line-window could be additionally emphasized by - for instance - inverted-color representation of that current difference, thereby again eliminating the need for a second cursor or even entering edit-mode altogether. But if edit-mode were invoked on purpose to make any changes the main window (with one cursor) would entirely suffice for doing that - as long as the target-differences for that editing could be automatically scrolled into the (center of) current field of view.

[ghisler(Author)]

Would it be possible to scroll the the two line compare window, so that the middle of the window shows the position of the F2-cursor in the main panel?

No, this would not work, because the differences may not be aligned, or not even visible at the same time.

Example:
a.txt:

Code: Select all

line 1
xxx aaabaaa

b.txt:

Code: Select all

line 1
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx aaacaaa

Here the "b" and "c" are the second difference, which you can find with F2 in both files. But they aren't even visible at the same time in the lower two line window.

[georgeb]

Here the "b" and "c" are the second difference, which you can find with F2 in both files. But they aren't even visible at the same time in the lower two line window.

How so? As I see it the first difference in the example above between line "a" and "b" would be the 4th occurrence of letter "x" in line b instead of a blank in line a?

And this 4th "x" (together with the following block containing the rest of letters) could be highlighted (by again e.g. inverted color) without the use of any cursor.

[petermad]

Would it be possible to scroll the the two line compare window, so that the middle of the window shows the position of the F2-cursor in the main panel?

No, this would not work, because the differences may not be aligned, or not even visible at the same time.

Example:
a.txt:

Code: Select all

line 1
xxx aaabaaa

b.txt:

Code: Select all

line 1
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx aaacaaa

Here the "b" and "c" are the second difference, which you can find with F2 in both files. But they aren't even visible at the same time in the lower two line window.

Sure - I didn't expect both lines in the two-line panel to be centered (then you couldn't spot where the difference begins), but maybe scroll both lines (just as if you scroll the two-line panel manually), so that the first difference in either line is visible - most often differencies are close together, so they would both be visible in that case.

[AntonyD]

By the way, friends, can you tell me how I can scroll to the left/right this bottom two-line panel's content to see all its values?
Once again, I don't see normal scroll bars where they should be!
Again, the panel is made just for a tick to show its potential usefulness, but you can't actually use it...

[petermad]

2AntonDudarenko
Just hold the mouse cursor over the two-line panel and use the scroll wheel on your mouse.

OR:

<Two line list>
Shows the current line from the active side together with the corresponding line on the other side, to make it easier to spot small differences like added/removed characters. This list can be scrolled sideways via cursor left/right, PageUp/PageDown, Home/End, or the mouse wheel. It can be hidden with the icon on the left of the status line. Press Ctrl+Tab to jump from one of the main panels to this list and back.

[AntonyD]

Just hold the mouse cursor over the two-line panel and use the scroll wheel on your mouse.

already tried as an intuitive guess - does not work....

This list can be scrolled sideways via cursor left/right, PageUp/PageDown, Home/End

these ones work, but definitely this keyboard style of work does not look good for such valuable visual element of the window...
And which again emphasizes the need for clear and standard elements like scrollbars.

[petermad]

2AntonDudarenko

already tried as an intuitive guess - does not work....

Hmm, it works on all my computers, also with a fresh ini file, so it does not require any special setting of TC.

Does the scroll-wheel work for you otherwise in TC?

How about Ctrl+wheel:

24.03.21 Added: Compare by content: Ctrl+Mouse wheel now scrolls the two line panel at the bottom even when the mouse isn't on it. Ctrl+Alt+Mouse Wheel still scrolls by page (32/64)

[AntonyD]

so it does not require any special setting of TC.

initially I thought exactly the same, but the real life shows....

Does the scroll-wheel work for you otherwise in TC?

yep, easily....

How about Ctrl+wheel:

Hmmm, interesting but definitely not so visually marked behavior as it should be, imho...
And yes - it works...

[JOUBE]

Hi,

the truth is, since the [F2]/Shift+[F2] module exists, the bottom two-line window isn't even necessary anymore. This bottom two-line window was only an auxiliary construction, which was introduced because it was sometimes difficult to find differences in lines (and that was often not easy with the two-line window either).

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.

JO"Thanks to ghisler(author) for [F2]/Shift+[F2] module and - even more - for (very) long lines compare support"UBE