RFC re Thunderbird + imap-send

RFC re Thunderbird + imap-send

[Jeremy White]

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

Re: RFC re Thunderbird + imap-send

[Michael J Gruber]

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

Re: RFC re Thunderbird + imap-send

[Ben Bucksch]

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).

Re: RFC re Thunderbird + imap-send

[Jeremy White]

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

Re: RFC re Thunderbird + imap-send

[Jeremy White]

> 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 <grin>).

Cheers,

Jeremy