Created attachment 51261 [details] a diff that gets parsed only partially, or so kompare says. Version: 4.0.0 (using KDE 4.5.0) OS: Linux When I open a diff (made with diff -burNE file1 file2), kompare more often than not complains about "malformed diff" and tells me that not all lines are shown in the view. one such diff is attached. the same diff parses fine in older versions of kompare. Reproducible: Sometimes Steps to Reproduce: reproducibility sometimes = happens with a lot of diffs but not all of them. reproduce: open the attached diff in kompare. Actual Results: "the diff is malformed. some lines could not be parsed and will not be displayed in the diff view". Expected Results: I want to see all lines of the diff parsed, or a better explanation as to which ones were malformed. OS: Linux (i686) release 2.6.34-12-pae Compiler: gcc
Well, FYI, Kompare still displays the exact same thing as before, it just warns you that it might not be complete. I cannot reproduce this with the diff you attached, maybe it got mangled during processing? Please try reattaching it in a compressed format (.xz / .bz2 / .gz).
Created attachment 51274 [details] same diff but bzipped
*** This bug has been confirmed by popular vote. ***
I see the same sometimes when I do "svn diff | kompare -o -". If I do "svn diff fileX | kompare -o -" for all differing files separately, I do not get the error.
*** Bug 252371 has been marked as a duplicate of this bug. ***
I have done some analysis and debugging. The problem is that the svn diff output format is: Index: somedir/filename.xyz =================================================================== --- somedir/filename.xyz (revision 5) +++ somedir/filename.xyz (working copy) @@ -1,3 +1,48 @@ A = B -C = D Index: somedir/filename.abc =================================================================== --- somedir/filename.abc (revision 5) +++ somedir/filename.abc (working copy) @@ -1,3 +1,48 @@ A = B +C = D When parsing such file Kompare uses the CVS diff parser with universal format enabled. Unified parses skips first 2 lines (Index and ===) and moves to --- as it is recognized by the regexp. After parsing first hunk the iterator points at next "Index:" but unified parses expects (using function checkHeader()) that the iterator will point at "---" - and the malformed flag is set by checkHeader(). Because the parses actually skips the 'invalid' lines the files gets successfully parsed but the warning popup is still shown.
Hmmm, duh, I couldn't reproduce this in comment #1 because I was trying with 4.4.5 whereas I only committed the malformed diff checks to 4.5 (because of the added string). I can reproduce it now with 4.5.2 (and heck, is it annoying!), I'm working on fixing it.
SVN commit 1193415 by kkofler: Make the malformed diff check more tolerant to prevent choking on SVN-generated diffs or on diffs resulting from the use of diff >>. It could probably use a better fix than such simple whitelisting, but this should fix the annoyance for now. Tested on Fedora 13, kdelibs 4.5.2. BUG: 249976 M +3 -1 parserbase.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1193415
SVN commit 1193416 by kkofler: Make the malformed diff check more tolerant to prevent choking on SVN-generated diffs or on diffs resulting from the use of diff >>. It could probably use a better fix than such simple whitelisting, but this should fix the annoyance for now. Tested on Fedora 13, kdelibs 4.5.2. Backport revision 1193415 from trunk. CCBUG: 249976 M +3 -1 parserbase.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1193416
Fixed for the upcoming kdesdk 4.5.4 and 4.6.0 releases. Also fixed in Fedora packaging of 4.5.3 as of kdesdk-4.5.3-3.fc15.
It's fixed, thank you very much. Can you also look at #252359 ? Kompare still cannot parse some SVN diff outputs :/
Hmmm, and another issue with SVN diffs I just thought of now is that sometimes SVN writes lines like "Binary files X and Y differ" in the middle of a diff, which will also trigger the "malformed" complaint. And there I'm not sure how to whitelist them because SVN translates that text. (Plus, ideally, we probably want to display that information somehow, but 1. I don't know how to fit this in Kompare's UI and 2. I really don't know how to parse those messages, since they could be written in ANY language.)
PS: Actually, plain diff also reports binary files that differ in that broken way.
KDE 4.8.3, kompare 4.1.1, bug is back.
It's not back. What you're seeing is bug #252359, which is still open.
Actually in my case the diff I'm trying to parse is *not* generated from svn, I'm passing two folders as argoments to kompare that do not contain version information from .hg or anything other. There are lots of bitmap files and UTF16 files in the trees, maybe that is what diff chokes on?
*** Bug 339002 has been marked as a duplicate of this bug. ***
kompare 4.1.3, bug is still there.
Created attachment 129754 [details] a diff generated by dif -burNE that kompare chokes on
It complains about diff reporting that binary files differ, in a translated message that is not reasonably machine-parsable. I have no way to distinguish this from actually invalid diffs where some parts cannot be displayed. Hence, warning the user about the unparsable lines is by design.
And strictly speaking, the warning is actually correct, because the differing binary files cannot be displayed in the diff viewer. (We cannot even show which files differ because we cannot parse the translated messages.)
(In reply to Kevin Kofler from comment #22) > parse the translated messages... NOW we are finally getting somewhere. I created a script that unsets LANG and then just calls diff with all argumets passed to it, and told kompare to use that script instead of the regular diff command, and voila, no more "malformed diff" errors anymore. Don't even have to exclude image files by pattern anymore. maybe that script should be part of kompare... #!/bin/bash unset LANG /usr/bin/diff $@ sits in ~/bin on my home folder, and due to my $PATH gets preference before /usr/bin/diff...
That would not help with diffs coming from elsewhere (possibly downloaded from the Internet) that you open in Kompare.
guess i didn't make myself clear enough: if kompare has problems with non-english output from diff, then kompare should run diff in a way that ensures english output.
But Kompare can also be used to view diffs that are already in a .diff file. I cannot control how diff was run in that case.
(In reply to Kevin Kofler from comment #26) > But Kompare can also be used to view diffs that are already in a .diff file. > I cannot control how diff was run in that case. ...in which case we can tell the user about it. But that's no reason not to "do it right" when you *can* control how diff is run.
by the way, my script to run diff with LANG="" doesn't help anymore for some reason.
actually that last comment's invalid - the reason for the error *was* because of some binary files...