# RFC re Thunderbird + imap-send 5 messages from 2009-02-09 to 2009-02-10. Participants: Jeremy White, Michael J Gruber, Ben Bucksch. Thread: https://gitlist.dev/t/17681 ## Jeremy White, 2009-02-09 21:49 Subject: RFC re Thunderbird + imap-send Message-ID: <4990A4FF.6020404@codeweavers.com> URL: https://gitlist.dev/e/4990A4FF.6020404%40codeweavers.com ``` So, MajorDomo knows that what I'm trying is sick and twisted; I seem to have run afoul of the taboos: http://vger.kernel.org/majordomo-taboos.txt (ixnay on the ention may of ontentcay ypetay tmlhay :-/). So here is a pointer to a proposed patch to enable git-imap-send to work with Thunderbird, based on Ben's suggestion: http://www.codeweavers.com/~jwhite/0001-Add-an-option-to-wrap-a-patch-in-pre-in-git-imap-s.patch Essentially, with this patch, I add an html option to the imap-send server configuration block. If turned on, we structure each patch as html, inside of pre blocks. And, in fact, Thunderbird does automatically convert such an email into a plain/text, format=fixed email, that seems to diff cleanly with a regular git-format-patch result. Thoughts? Tar and feathers? Cheers, Jeremy ``` ## Michael J Gruber, 2009-02-10 11:06 Subject: Re: RFC re Thunderbird + imap-send Message-ID: <49915FB6.8010803@drmicha.warpmail.net> URL: https://gitlist.dev/e/49915FB6.8010803%40drmicha.warpmail.net In-Reply-To: <4990A4FF.6020404@codeweavers.com> ``` Jeremy White venit, vidit, dixit 09.02.2009 22:49: > So, MajorDomo knows that what I'm trying is sick and twisted; I seem to > have run afoul of the taboos: > http://vger.kernel.org/majordomo-taboos.txt > > (ixnay on the ention may of ontentcay ypetay tmlhay :-/). > > So here is a pointer to a proposed patch to enable git-imap-send to work > with Thunderbird, based on Ben's suggestion: > > http://www.codeweavers.com/~jwhite/0001-Add-an-option-to-wrap-a-patch-in-pre-in-git-imap-s.patch > > Essentially, with this patch, I add an html option to the imap-send > server configuration block. If turned on, we structure each patch as > html, inside of pre blocks. And, in fact, Thunderbird does > automatically convert such an email into a plain/text, format=fixed > email, that seems to diff cleanly with a regular git-format-patch result. > > Thoughts? Tar and feathers? Looks okay here. I leave the tarring and feathering to Dscho ;) Trying this out showed that indeed git-imap-send needs much more love. The man page doesn't say much, doesn't describe all options. Most options can be specified in config only. You can't pass file arguments, only stdin. You can't even pass a recipient! To be useful, imap-send should really obey the same config options and parameters as much as possible. In fact they should share some. imap-send and send-email should be usable interchangeably, without fiddling with format-patch options (which has to: and cc: where it doesn't really belong). Uhm, I'm getting off-topic. Back on topic: TB does the automatic conversion to plain text only when the send options are appropriate, or if you set the recipient to "text only". Also: For a typical text mail in Drafts I see lines like X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; uuencode=0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Any chance we could use that rather than invoke the HTML editor? We would need to shut off q-p and f-f *and* avoid automatic word wrap (or make sure patches don't have longer lines then TBs editor allows), the latter I don't know how to do. Michael ``` ## Ben Bucksch, 2009-02-10 12:24 Subject: Re: RFC re Thunderbird + imap-send Message-ID: <49917208.6000807@beonex.com> URL: https://gitlist.dev/e/49917208.6000807%40beonex.com In-Reply-To: <49915FB6.8010803@drmicha.warpmail.net> ``` On 10.02.2009 12:06, Michael J Gruber wrote: > For a typical text mail in Drafts I see lines like > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: quoted-printable > Any chance we could use that rather than invoke the HTML editor? > We would need to shut off q-p and f-f *and* avoid automatic word wrap > (or make sure patches don't have longer lines then TBs editor allows), > the latter I don't know how to do. > I'm not aware that existing headers would influence the send logic (in turning on/off qp or f=f or word wrap). ``` ## Jeremy White, 2009-02-10 13:23 Subject: Re: RFC re Thunderbird + imap-send Message-ID: <49917FC4.3000807@codeweavers.com> URL: https://gitlist.dev/e/49917FC4.3000807%40codeweavers.com In-Reply-To: <49917208.6000807@beonex.com> ``` Ben Bucksch wrote: > On 10.02.2009 12:06, Michael J Gruber wrote: >> For a typical text mail in Drafts I see lines like >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: quoted-printable >> Any chance we could use that rather than invoke the HTML editor? >> We would need to shut off q-p and f-f *and* avoid automatic word wrap >> (or make sure patches don't have longer lines then TBs editor allows), >> the latter I don't know how to do. >> > I'm not aware that existing headers would influence the send logic (in > turning on/off qp or f=f or word wrap). I both looked at the Thunderbird code and experimented with a variety of options and found no way to do this; only the charset seems to be picked up (and that may actually be a bug, judging by Ben's initial reaction :-/). Cheers, Jeremy ``` ## Jeremy White, 2009-02-10 19:00 Subject: Re: RFC re Thunderbird + imap-send Message-ID: <4991CEE9.8040402@codeweavers.com> URL: https://gitlist.dev/e/4991CEE9.8040402%40codeweavers.com In-Reply-To: <49915FB6.8010803@drmicha.warpmail.net> ``` > Looks okay here. I leave the tarring and feathering to Dscho ;) Thanks. > > Trying this out showed that indeed git-imap-send needs much more love. > The man page doesn't say much, doesn't describe all options. Most > options can be specified in config only. You can't pass file arguments, > only stdin. You can't even pass a recipient! Hmm. I think the documentation/man page is correct, at least in the tip; Rob Shearman fixed it back in July. I think your larger concerns about git-imap-send are valid; it does seem that having two paths for emailing patches is less than ideal. But I'm going to cowardly claim that is outside of my scope at this point. (I like starting flame wars and all, but adding --html to git-send-email just seems like a poor choice for my health ). Cheers, Jeremy ```