LineDiff: WinMerge 2.7.4.0 shows difference wrong
Windows visual diff and merge for files and directories
Brought to you by:
christianlist,
grimmdp
While I was merging a Visual Basic project with WinMerge 2.7.4.0, I found a visual bug: The left side shows content in the different line, that not exists. But WinMerge copies the line correct to the right side.
PHYSICAL
--------
Left:
'| 2005 Tim Gerundt |
Right:
'| 2005-2007 Tim Gerundt |
VISIBLE
-------
Left:
'| 2005 Tim Gerundt | |
Right:
'| 2005-2007 Tim Gerundt |
I tested it with WinMerge 2.7.4.0 under a German Windows XP.
Greetings,
Tim
test files
screenshot from the bug
Logged In: YES
user_id=652377
Originator: YES
File Added: winmerge_shows_diff_wrong.png
WinMerge 2.7.4.0 configuration
Logged In: YES
user_id=652377
Originator: YES
File Added: winmerge_config_2740.txt
Logged In: YES
user_id=652377
Originator: YES
WinMerge 2.7.3.7 don't have the problem.
Logged In: YES
user_id=631874
Originator: NO
Well.. Linediff is in pretty sad situation, it seems.
For 2.7.4 I applied Gal's patch which fixed showing whitespace differences (which is must-to-have). But it apparently caused another bug (once again).
The fact is linediff has never worked good. And we just seem to have different sets of bugs with different patches.
Logged In: YES
user_id=631874
Originator: NO
What really is needed somebody to define how difference highlight should work, as detailed as possible. I don't mean in code-level but how it looks for user. What textual differences are highlighted and how?
That is the only way we can hope we get something really working implementation some day. As long as we only tweak something there and there it won't ever get working properly. If you have some free time, you can help a lot by starting writing initial specification to wiki. Does not need to be formal, just describing how this feature should work and how it highlights differences in different cases.
Logged In: YES
user_id=652377
Originator: YES
I today merged the latest CVS version from the (PHP project) WebCalendar <webcalendar.sourceforge.net> with my local version. There was many whitespace changes in the PHP files and the bug got really annoying! Many lines was shown wrong, because of some added whitespace chars. For example:
PHYSICAL
--------
Left:
unset ( $config_lines );
Right:
unset( $config_lines );
VISIBLE
-------
Left:
unset ( $config_lines );( $config_lines );
Right:
unset( $config_lines );
> starting writing initial specification to wiki.
Currently I work on a script to get a realtime translation status. After that I will look at this.
Logged In: YES
user_id=652377
Originator: YES
I just noticed, that the bug only appears, if I use "Character level" for line difference coloring.
Logged In: YES
user_id=631874
Originator: NO
That is a good observation! I had to "push" about this char-level highlighting, as he was only fixing and testing word-level highlighting. And I think word-level highlighting isn't all that interesting after all. Char-level is what I need to see in my usual use.
Also, one thing that worries me (a lot!) is how we really can keep this highlighting diffutils-compatible. Its easy when comparing all differences, but what about when ignoring whitespaces?
Logged In: YES
user_id=631874
Originator: NO
By the way, have you tried that Geek's version of WinMerge? Does the line highlighting work better in it?
Logged In: YES
user_id=652377
Originator: YES
> By the way, have you tried that Geek's version of WinMerge?
I wanted, but I have no VC8 (VS2005) runtime libraries installed and can't execute his binaries. And his sources have no VC6 project file. :(
Logged In: YES
user_id=652377
Originator: YES
I found just a string combination, which even makes WinMerge 2.7.6.0 with the new *old* linediff engine to show "ghost" content:
PHYSICAL
--------
Left:
<a href="<?php echo $_SERVER['PHP_SELF']; ?>"> ?></a>
Right:
<?php echo convertLang2Html($html_inbox); ?>
VISIBLE
-------
Left:
<a href="<?php echo $_SERVER['PHP_SELF']; ?>"> ?></a>
Right:
<?php echo convertLang2Html($html_inbox); ?> convertLang2Html($html_inbox); ?>
Logged In: YES
user_id=631874
Originator: NO
That is bad news, as it means 2.6.12 stable shows ghost content.
Can you try early 2.6.x versions (2.6.0, 2.6.2 etc) to see if they all show that ghost content. Maybe there is working version among them..
Logged In: YES
user_id=652377
Originator: YES
> Can you try early 2.6.x versions (2.6.0, 2.6.2 etc) to see if they all
> show that ghost content. Maybe there is working version among them..
Mhh, I tested 2.6.0, 2.6.2, 2.6.8 and 2.6.12 and non version shows the ghost content! Maybe you not reverse all changes?
Logged In: YES
user_id=631874
Originator: NO
Thanks a lot for that testing!
I'm pretty sure I reverted *linediff* changes. So your testing suggests the bug is elsewhere in the editor code.. So there might be some bad interaction with linediff and other editor code which causes this.
Logged In: YES
user_id=631874
Originator: NO
Hmm.. There actually is two differences I didn't revert. I wonder why.. There are two diffs in Src/stringdiffs.cpp.
Patch to revert couple of lines I missed
Logged In: YES
user_id=631874
Originator: NO
Can you try the attached patch. It reverts two lines I missed earlier. And seems after this patch your latest case works for me:
Index: stringdiffs.cpp
--- stringdiffs.cpp (revision 4839)
+++ stringdiffs.cpp (working copy)
@@ -788,8 +788,6 @@
else
end2 = pz2 - pbeg2;
- if (end1 < begin1) begin1 = -1;
- if (end2 < begin2) begin2 = -1;
}
}
File Added: StringDiffRevert_v2.patch
Logged In: YES
user_id=652377
Originator: YES
> Can you try the attached patch.
Yes, the patch fix it for me too!
I just noticed, that WinMerge 2.7.6.0 (with and without patch) still have problems with the strings from the initial bug report:
Left:
'| 2005 Tim Gerundt |
Right:
'| 2005-2007 Tim Gerundt |
WinMerge 2.6.* have no problems with the strings.
Logged In: YES
user_id=631874
Originator: NO
Ok, reverting couple of remaining different lines in stringdiffs.cpp fixed that original bug too. So almost every line had its own bug. :(
Committed to SVN trunk:
Completed: At revision: 4840
Logged In: YES
user_id=631874
Originator: NO
Oh, forgot to close this one..