ticket change notification should contain diff'ed text, not old and new

[ThurnerRupert]

it would be beneficial, if the notification mail on a ticket change containes a diff'ed output instead of the old and new text. especially when a description is long and just a little thing changed its quite a challenge to find out what changed.

[Christian Boos]

What about the diff with the full context?

[anonymous]

Replying to cboos:

What about the diff with the full context?

would be even better :)

[Matthew Good]

Replying to cboos:

What about the diff with the full context?

Be sure to take into account the line wrapping. Descriptions will probably have long lines that get wrapped for the email, so they'll need diffed after wrapping so the diff doesn't get screwed up.

[Emmanuel Blot]

Replying to mgood:

Be sure to take into account the line wrapping. Descriptions will probably have long lines that get wrapped for the email, so they'll need diffed after wrapping so the diff doesn't get screwed up.

Base64 encoding can avoid this issue (as the base64 stream encode the line feed as any other characters). Other encoding schemes (such as QP) are subject to this issue.

Another solution is to make diff'ed text appear as attached files, not inlined within the notification text. Attaching documents to notification would require some careful rework, as previous attempts to use multipart email messages have led to unexpected difficulties.

Anyway, IMHO such a feature could be a candidate for 0.12 rather than 0.11

[Matthew Good]

Replying to eblot:

Replying to mgood:

Be sure to take into account the line wrapping. Descriptions will probably have long lines that get wrapped for the email, so they'll need diffed after wrapping so the diff doesn't get screwed up.

Base64 encoding can avoid this issue (as the base64 stream encode the line feed as any other characters). Other encoding schemes (such as QP) are subject to this issue.

No, that's not really what I meant. I'm not sure I understand why the encoding would affect the display. What I mean is that for email display you'll want to wrap the lines in the description so they don't run off the screen. Doing this after doing the diff will produce incorrect diffs like:

- this is the old
description getting
wrapped
+ this is the new
description also
being wrapped

Which would be better displayed as:

- this is the old
- description getting
- wrapped
+ this is the new
+ description also
+ being wrapped

[Emmanuel Blot]

Replying to mgood:

No, that's not really what I meant. I'm not sure I understand why the encoding would affect the display.

Oh ok, I got it.
About the encoding: email data line should be limited to 76 characters (according to RFC822), so Trac needs to introduce line breaks before sending the email. However with Base64, the original line breaks do not matter, as they never appear in the data sent over SMTP: MIME/Base64 adds its own line breaks that are unrelated with the encoded line breaks.

Nevertheless, I did not though about email display on the MUA, so you can forget about my comment, even though we might need to introduce multipart MIME message at some point.

[Christian Boos]

Probably 0.12.

[osimons]

#6664 is working to make a diff available for the web ui. I have noted the question of email diffs on that ticket.

[Christian Boos]

#8503 was closed as duplicate.

[Christian Boos]

#8862 was closed as duplicate. If the patch is resubmitted here with the requested changes, we can move that ticket to 0.12.

[Dave Gray <trac@…>]

patch from #8862 updated to display entire context and hide header

[Dave Gray <trac@…>]

patch from #8862 has been updated and is attached

[lkraav <leho@…>]

i was about to file an enhancement bug regarding missing diff links in ticket description change rss feed.

searched through tickets with "ticket description diff", found this and am now wondering if this ticket applies to my question as well?

[Ryan J Ollos]

#13001 closed as a duplicate.

[Ryan J Ollos]

Let's consider for 1.4.

[Ryan J Ollos]

Milestone renamed