Bug 1000711
| Summary: | why can "kompare" not read these files? | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Harald Reindl <h.reindl> | ||||||
| Component: | kompare | Assignee: | Kevin Kofler <kevin> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 18 | CC: | jgrulich, kevin, ltinkl, rdieter, than | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2013-08-25 22:29:46 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Hi Harry, I'm taking this one because I'm the upstream maintainer for Kompare. You will probably not like this, but unfortunately, I have to say that this doesn't look like a bug to me: * test1.diff contains a space where diff normally outputs a tab. So it looks like tab expansion in your terminal emulator butchered that diff. This is why Kompare's diff parser does not accept the diff. * test2.diff is actually accepted by Kompare with a warning. (At least it is on my machine! Please let me know if this doesn't work for you.) The explanation for the warning is that your paste contains an additional newline. So when Kompare counts the lines in the diff, it notices that there's a line which is not accounted for by the "@@ -5901,4 +5901,3 @@" header, which announces exactly 4 lines. So it ignores the excess line, and I have explicitly been asked by other users to output a warning about that (see https://bugs.kde.org/show_bug.cgi?id=235503), because otherwise users could miss important changes with no indication whatsoever if something was wrong with the diff. (Note that test1.diff has the same problem, but Kompare's parser doesn't even get that far there because of the expanded tab.) Removing the excess newline should make the warning go away. * The reason the Kate syntax highlighter can display both files just fine is that a syntax highlighter can actually tolerate much more than a full parser can, because it needs only a partial and local understanding of the file. (See e.g. how the highlighter can easily get confused if you have a diff removing a line starting with --, as happens e.g. in Haskell code; I've seen it color that as a --- line. That shows how the highlighter isn't fully parsing the diff, but only matching certain regexes.) The best way to get output into Kompare is still to pipe the result of diff directly into a file. (Can't you pipe it to the tee command in your web app, to get the output both on screen and into a file?) That way, you'll be sure that the file will not have been corrupted by a terminal emulator. Terminal emulators are really bad at preserving characters. Greetings from Wien-Neubau and sorry that I have to close this bug, Kevin Oops, nevermind the terminal emulator part, you said you formatted it to a web page and copied that as plain text. But there too, that can change characters, as evidenced by your test1.diff. Outputting the file directly as a plain text file (which web browsers should be able to display just fine) is a more reliable way to get it into Kompare (or other similar applications). (The MIME type to use is text/x-patch.) (I still stand by the rest of my message. ;-) ) Created attachment 790176 [details]
screenshot
well, i modified my web-application to store the generated diff in i'ts temp-folder with a predictable name and add a token- and session-protected download link at the right side of the HTML output, now i have to find a way to delete these temp-files at least a day later to not ivalidate the link at the first click by delete after passthru()
however, it does not make me too happy that"kompare" is taht sensible about tabs and new-lines at the end of the file - the latter is *always* added by nano at the end of a file - you can't practically save a file with nano not containing a newline at the end
Well, I need to look into making the parser more tolerant to finally fix https://bugs.kde.org/show_bug.cgi?id=252359 anyway (Maybe it should just silently skip lines not starting with +, - or a space?), with some luck, that should also make it less picky about newlines. But I'm not promising anything right now. no problem, the webinterface from the screenshot was developed due my current upstream help for http://www.dbmail.org/ fixing some ugly bugs and making a lot of tests... well i was not that lucky that i needed also to implement direct downloads while i had results on the screen to compare which is not that easy in case of 1000 iterations and 10 differences because you have this data only for one moment and http is stateless - but now it's done and today even a mailparser went just for fun in the backend :-) |
Created attachment 789856 [details] two copy&paste diffs from the website i have writtena web-application which compares messages from IMAP/POP3 and if there is a difference calls a command like "diff -U 3 -dHrN 'imap_c4fd87b328cc9e9792ceaacf96107b38.eml' 'pop3_316f3890d7b8feb7dbbce858073a1c8b.eml'" via PHP popen()/fread() and outputs the diff in a text-filed correctly handeled with htmlentities * kate shows the diff with colors and highligtning * kompare does not accept two different copy&paste to a textfile