Bug 3035

Summary: Enhance diff coloring to git patches
Product: Claws Mail (GTK 2) Reporter: Jakub Kici&#324;ski <kubakici>
Component: UI/Message ViewAssignee: users
Status: RESOLVED DUPLICATE    
Severity: enhancement    
Priority: P3    
Version: 3.9.3   
Hardware: PC   
OS: All   
Attachments:
Description Flags
git generated patch to fix format detection
none
git generated patch to add in-email patch detection none

Description Jakub Kici&#324;ski 2013-12-11 17:31:07 UTC
Created attachment 1308 [details]
git generated patch to fix format detection

Fix diff format detection and add detection of diffs inside emails (for mailing list patch submission).
Comment 1 Jakub Kici&#324;ski 2013-12-11 17:33:21 UTC
Created attachment 1309 [details]
git generated patch to add in-email patch detection
Comment 2 Andrej Kacian 2013-12-12 17:52:51 UTC
This is something we discussed when the diff coloring for attachments was added. The "gittiness" detection in your patch is quite naive, and will likely yield many false positives (diff coloring used when it shouldn't be). All that's needed is someone mentioning string "git --diff" in their mail, without it being an actual git-generated mail with diff output.

If anything, maybe check for presence of X-Git-... message headers, or something else that can reliably tell we're dealing with mail that has to be diff-colored. And I'm not sure whether it is a good idea to go down this path. Any more opinions?
Comment 3 Jakub Kici&#324;ski 2013-12-13 18:35:00 UTC
Thank you for the review!

I implemented the detection in the quickest and simplest way possible. I used it for a year or so and there where no false positives so far... 

I'm open to any suggestions. Three things that I thought about that can mitigate false positives are:

1 - detect X-Mailer: git-send-email -- a lot of people seem to send their patches from MUAs though, especially when they send the patch as a part of a discussion, not for submission.

2 - make detection of "diff --git" more robust by matching the file names and following "index ..." line.

3 - match subject to PATCH and RFC -- again would cause false negatives

Also maybe a configuration option which defaults to off for matching diffs inside emails would solve the problem? At least users would know where the false-positives come from if they appear and this feature is probably only useful for a small percentage of CM users?

Thanks, and I'm waiting for further opinions/suggestions!
Comment 4 Paul 2018-12-02 12:35:57 UTC

*** This bug has been marked as a duplicate of bug 4130 ***