[Virtual PATCH] Add an option to wrap a patch in <pre> in git-imap-send which ironically results in a cleaner patch from Thunderbird.

[Virtual PATCH] Add an option to wrap a patch in <pre> in git-imap-send which ironically results in a cleaner patch from Thunderbird.

[Jeremy White]

Due to Major Domo limitations, the following patch cannot be send normally to the list.

It is available here:

http://www.codeweavers.com/~jwhite/0001-Add-an-option-to-wrap-a-patch-in-pre-in-git-imap-s-v2.patch

This version reflects suggested improvements to the text by Jay Soffian.

Cheers,

Jeremy

Re: [Virtual PATCH] Add an option to wrap a patch in <pre> in git-imap-send which ironically results in a cleaner patch from Thunderbird.

[Junio C Hamano]

I do not think of a reason, other than to trigger the workaround you
mentioned in the documentation part of the patch, why any sane user would
want to send a patch as HTML.  This configuration variable sounds more
like "imap.forceThunderbirdToSendNonFlowedTextByExploitingItsBug" than
"imap.html", in other words.

What worries me the most is if there is any guarantee that this bug you
are exploiting to force it to send a patch in the common denominator
format _will not be fixed_ in future versions of Thunderbird.

I see your patch deals only with ampersand, less-than, greater-than and
dquot.  Do you know if this is enough, or would letters outside US-ASCII
need to be expressed in ampersand-hash "character reference" notation?

Re: [Virtual PATCH] Add an option to wrap a patch in <pre> in git-imap-send which ironically results in a cleaner patch from Thunderbird.

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 13.02.2009 05:19:
> I do not think of a reason, other than to trigger the workaround you
> mentioned in the documentation part of the patch, why any sane user would
> want to send a patch as HTML.  This configuration variable sounds more
> like "imap.forceThunderbirdToSendNonFlowedTextByExploitingItsBug" than
> "imap.html", in other words.
> 
> What worries me the most is if there is any guarantee that this bug you
> are exploiting to force it to send a patch in the common denominator
> format _will not be fixed_ in future versions of Thunderbird.

It's not a bug, it's a feature ;)

In fact it really is: preformatted text in HTML (<pre>) is by definition
left alone. Now, when you are about to send an HTML mail TB asks you
what to do (or takes a choice from preferences/addressbook): send as
HTML, as text or both.

The fact that the current HTML->text converter respects preformated text
without reflowing (and without f-f, which would allow reflowing on the
receiving side) is a feature. TB trys to represent the HTML in text form
as closely as possible.

> I see your patch deals only with ampersand, less-than, greater-than and
> dquot.  Do you know if this is enough, or would letters outside US-ASCII
> need to be expressed in ampersand-hash "character reference" notation?

According to Ben of Mozilla fame this is enough for special characters.
I don't know about UTF-8, though. Usually, TB recognizes the proper
encoding.

Michael J Gruber

Re: [Virtual PATCH] Add an option to wrap a patch in <pre> in git-imap-send which ironically results in a cleaner patch from Thunderbird.

[Jeremy White]

Michael J Gruber wrote:
> Junio C Hamano venit, vidit, dixit 13.02.2009 05:19:
>> I do not think of a reason, other than to trigger the workaround you
>> mentioned in the documentation part of the patch, why any sane user would
>> want to send a patch as HTML.  This configuration variable sounds more
>> like "imap.forceThunderbirdToSendNonFlowedTextByExploitingItsBug" than
>> "imap.html", in other words.

With Michael's proviso well in hand (it's a feature, not a bug), I
did want to say that I otherwise think this is a reasonable analysis.

In fact, calling the option imap.thunderbird-fixed-html is arguably a
better name.

Finally, I know it's my patch, but for the record, I won't be hurt if
it's round filed.  You can make a clean case that not taking
it in leaves pressure on the joint dev communities to find a better 
solution.

But the only better approach I can imagine is if Thunderbird were
to respect a 'format=fixed' injected in a message body.  However,
as I think about that, I believe a correct Thunderbird implementation
of that would require having a per message setting for format.
The Thunderbird team is very reluctant to expose any UI on
f=f (see https://bugzilla.mozilla.org/show_bug.cgi?id=86607),
so having a per message UI element certainly sounds like a dead
idea walking :-/.

Cheers,

Jeremy

Re: [Virtual PATCH] Add an option to wrap a patch in <pre> in git-imap-send which ironically results in a cleaner patch from Thunderbird.

[Ben Bucksch]

>
> I do not think of a reason, why any sane user would
> want to send a patch as HTML.

The patch is not sent as HTML. It is merely passed to the mailer as HTML.
The "reason" is that HTML allows more information: It allows to separate 
human language text from preformatted text / source code.

Human language text follows other rules in some (I'll call them "more 
capable", to be just as advocating) mailers than others: text flow / 
wrapping, link and quote recognition etc.pp. all make sense for human 
language text / normal emails, but not for source code. Plain text is 
inherently limited in which information it can convey (no links, no 
quotes, no flow etc.pp.).

For more information, see the long email thread that preceeded. I don't 
feel like repeating it.

> This configuration variable sounds more
> like "imap.forceThunderbirdToSendNonFlowedTextByExploitingItsBug" than
> "imap.html", in other words.

I agree that "html" is not a good wording, given the immediate disgust 
that it invokes with many people in the community. (Which is partially 
warranted, and partially irrational.)

I'd propose a less inflammatory wording (and posts):
imap.preformatted
imap.thunderbird
(The first is better, because other mailers might have the same problem, 
now or in the future, and might benefit from the same workaround).

> What worries me the most is if there is any guarantee that this bug you
> are exploiting

FWIW, it's not a bug that he's exploiting.
mailto:foo@example.com?subject=""&html-body="" is a feature (not sure if 
documented).

> _will not be fixed_ in future versions of Thunderbird.

What you see is not a bug in Thunderbird.

> I see your patch deals only with ampersand, less-than, greater-than and
> dquot. Do you know if this is enough

Yes, this is enough to escape literals in HTML code.

> or would letters outside US-ASCII
> need to be expressed in ampersand-hash "character reference" notation?

If so, this this was a bug before and after the patch. What matters for 
non-ascii is the charset, and that's the same problem for plaintext and 
HTML. You'll just have to set the right charset header, and I think he 
does that.

Re: [Virtual PATCH] Add an option to wrap a patch in <pre> in git-imap-send which ironically results in a cleaner patch from Thunderbird.

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

>> What worries me the most is if there is any guarantee that this bug you
>> are exploiting to force it to send a patch in the common denominator
>> format _will not be fixed_ in future versions of Thunderbird.
>
> It's not a bug, it's a feature ;)
>
> In fact it really is: preformatted text in HTML (<pre>) is by definition
> left alone. Now, when you are about to send an HTML mail TB asks you
> what to do (or takes a choice from preferences/addressbook): send as
> HTML, as text or both.

Ok, "TB asks you what to do and you choose 'text-only'" is the part I
missed.  In that case, I'd agree it definitely is a feature not to use
flowed to convert that <pre>..</pre> to a plain text.  Thanks for an
explanation.

>> I see your patch deals only with ampersand, less-than, greater-than and
>> dquot.  Do you know if this is enough, or would letters outside US-ASCII
>> need to be expressed in ampersand-hash "character reference" notation?
>
> According to Ben of Mozilla fame this is enough for special characters.
> I don't know about UTF-8, though. Usually, TB recognizes the proper
> encoding.

Yeah, anything outside US-ASCII.  That was what I was wondering about.