Hi,

a quick fix to let Thunderbird (and other webmails) see patch
attachments.

This mail is sent with the patch applied so that you can see the result.

Best,
Gabriel

1 patch for repository http://darcs.net/screened:

Wed Aug 31 19:10:52 CEST 2011  Gabriel Kerneis <kerneis@pps.jussieu.fr>
  * resolve issue2099: inline patch preview

Attachments

• patch-preview.txt
• resolve-issue2099_-inline-patch-preview.dpatch
• unnamed

On Wed, Aug 31, 2011 at 17:26:55 +0000, Gabriel Kerneis wrote:
> a quick fix to let Thunderbird (and other webmails) see patch
> attachments.

+1 although note that my "understanding" of MIME comes from skimming
Wikipedia rather than actually reading RFCs

> This mail is sent with the patch applied so that you can see the result.

Works great from mutt!

resolve issue2099: inline patch preview
---------------------------------------
> - $$ text "Content-Type: multipart/mixed; boundary=\"=-\""
> + $$ text "Content-Type: multipart/mixed; boundary=\"=_\""

Is this the heart of the change?  I have the impression that
your patch is a bug fix because it uses consistent boundaries.

Out of interest, what do we do about the '=_' which could easily
appear in the attachment body? This is not specific to your patch,
just something I did not quite get from reading Wikipedia.
Are we just counting on low probability here?

-- 
Eric Kow <http://erickow.com>

Oh, I did also see the Content-disposition: inline (which I guess 
accounts for your patch title).  

Random stuff on my mind:

Roundup thinks that darcs patch e-mails have a mystery final  attachment 
with the contents "."  Perhaps after understanding this code, you know 
why?

Finally, shouldn't we be using one of the MIME libraries on hackage?

On Tue, Sep 06, 2011 at 04:49:44PM +0100, Eric Kow wrote:
> resolve issue2099: inline patch preview
> ---------------------------------------
> > - $$ text "Content-Type: multipart/mixed; boundary=\"=-\""
> > + $$ text "Content-Type: multipart/mixed; boundary=\"=_\""
> 
> Is this the heart of the change?

No, the heart of the change is to remove the "alternative" multipart stuff, to
keep two separate attachments (the patch and the preview), instead of two
alternative views of a single attachment.

The line you quoted is necessary because "darcs apply" has the "=_" boundary
hard-coded (it does not parse MIME attachments properly), so we must manage to
end the part containing the attachment with "--=_--" for backward-compatibility
reasons.

> Out of interest, what do we do about the '=_' which could easily
> appear in the attachment body? This is not specific to your patch,
> just something I did not quite get from reading Wikipedia.
> Are we just counting on low probability here?

I think so.

Then again, we could improve darcs apply to cope with arbitrary boundaries, but
backward-compatibility prevents us from changing darcs send (we could at least
try to detect the issue and fail before sending when it happens).

Best,
-- 
Gabriel

On Tue, Sep 06, 2011 at 04:05:43PM +0000, Eric Kow wrote:
> Roundup thinks that darcs patch e-mails have a mystery final  attachment 
> with the contents "."  Perhaps after understanding this code, you know 
> why?

makeEmail (in Email.hs) emits a final dot on a single line at the end of the
message.  I suppose it used to be there to mark the end of the mail for
sendmail, but is no longer necessary because the code evolved and it is now
sent as part of the email.

It should be safe to remove it, but I did not check every send method
(sendmail, windows, others?).

Most mailers do not display it because it is outside mime boundaries, I guess.

Best,
-- 
Gabriel