{"thread":{"id":"17752","subject":"[Virtual PATCH] Add an option to wrap a patch in 
 in git-imap-send which ironically results in a cleaner patch from Thunderbird.","startedAt":"2009-02-12T15:57:04Z","lastAt":"2009-02-13T17:49:15Z","messageCount":6,"participants":["Jeremy White","Junio C Hamano","Michael J Gruber","Ben Bucksch"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"104394","messageId":"499446D0.90602@codeweavers.com","threadId":"17752","inReplyTo":null,"subject":"[Virtual PATCH] Add an option to wrap a patch in 
 in git-imap-send which ironically results in a cleaner patch from Thunderbird.","fromName":"Jeremy White","fromEmail":"jwhite@codeweavers.com","sentAt":"2009-02-12T15:57:04Z","receivedAt":"2009-02-12T15:57:04Z","isPatch":true,"sender":{"key":"jwhite@codeweavers.com","avatar":"https://avatars.githubusercontent.com/u/1063742?v=4"},"body":"Due to Major Domo limitations, the following patch cannot be send normally to the list.\n\nIt is available here:\n\nhttp://www.codeweavers.com/~jwhite/0001-Add-an-option-to-wrap-a-patch-in-pre-in-git-imap-s-v2.patch\n\nThis version reflects suggested improvements to the text by Jay Soffian.\n\nCheers,\n\nJeremy\n"},{"id":"104473","messageId":"7viqnfezo5.fsf@gitster.siamese.dyndns.org","threadId":"17752","inReplyTo":"499446D0.90602@codeweavers.com","subject":"Re: [Virtual PATCH] Add an option to wrap a patch in 
 in git-imap-send which ironically results in a cleaner patch from Thunderbird.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-13T04:19:54Z","receivedAt":"2009-02-13T04:19:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I do not think of a reason, other than to trigger the workaround you\nmentioned in the documentation part of the patch, why any sane user would\nwant to send a patch as HTML.  This configuration variable sounds more\nlike \"imap.forceThunderbirdToSendNonFlowedTextByExploitingItsBug\" than\n\"imap.html\", in other words.\n\nWhat worries me the most is if there is any guarantee that this bug you\nare exploiting to force it to send a patch in the common denominator\nformat _will not be fixed_ in future versions of Thunderbird.\n\nI see your patch deals only with ampersand, less-than, greater-than and\ndquot.  Do you know if this is enough, or would letters outside US-ASCII\nneed to be expressed in ampersand-hash \"character reference\" notation?\n"},{"id":"104509","messageId":"49955860.80504@drmicha.warpmail.net","threadId":"17752","inReplyTo":"7viqnfezo5.fsf@gitster.siamese.dyndns.org","subject":"Re: [Virtual PATCH] Add an option to wrap a patch in 
 in git-imap-send which ironically results in a cleaner patch from Thunderbird.","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-02-13T11:24:16Z","receivedAt":"2009-02-13T11:24:16Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 13.02.2009 05:19:\n> I do not think of a reason, other than to trigger the workaround you\n> mentioned in the documentation part of the patch, why any sane user would\n> want to send a patch as HTML.  This configuration variable sounds more\n> like \"imap.forceThunderbirdToSendNonFlowedTextByExploitingItsBug\" than\n> \"imap.html\", in other words.\n> \n> What worries me the most is if there is any guarantee that this bug you\n> are exploiting to force it to send a patch in the common denominator\n> format _will not be fixed_ in future versions of Thunderbird.\n\nIt's not a bug, it's a feature ;)\n\nIn fact it really is: preformatted text in HTML (
) is by definition\nleft alone. Now, when you are about to send an HTML mail TB asks you\nwhat to do (or takes a choice from preferences/addressbook): send as\nHTML, as text or both.\n\nThe fact that the current HTML->text converter respects preformated text\nwithout reflowing (and without f-f, which would allow reflowing on the\nreceiving side) is a feature. TB trys to represent the HTML in text form\nas closely as possible.\n\n> I see your patch deals only with ampersand, less-than, greater-than and\n> dquot.  Do you know if this is enough, or would letters outside US-ASCII\n> need to be expressed in ampersand-hash \"character reference\" notation?\n\nAccording to Ben of Mozilla fame this is enough for special characters.\nI don't know about UTF-8, though. Usually, TB recognizes the proper\nencoding.\n\nMichael J Gruber\n"},{"id":"104517","messageId":"49957AAE.7070505@codeweavers.com","threadId":"17752","inReplyTo":"49955860.80504@drmicha.warpmail.net","subject":"Re: [Virtual PATCH] Add an option to wrap a patch in 
 in git-imap-send which ironically results in a cleaner patch from Thunderbird.","fromName":"Jeremy White","fromEmail":"jwhite@codeweavers.com","sentAt":"2009-02-13T13:50:38Z","receivedAt":"2009-02-13T13:50:38Z","isPatch":true,"sender":{"key":"jwhite@codeweavers.com","avatar":"https://avatars.githubusercontent.com/u/1063742?v=4"},"body":"Michael J Gruber wrote:\n> Junio C Hamano venit, vidit, dixit 13.02.2009 05:19:\n>> I do not think of a reason, other than to trigger the workaround you\n>> mentioned in the documentation part of the patch, why any sane user would\n>> want to send a patch as HTML.  This configuration variable sounds more\n>> like \"imap.forceThunderbirdToSendNonFlowedTextByExploitingItsBug\" than\n>> \"imap.html\", in other words.\n\nWith Michael's proviso well in hand (it's a feature, not a bug), I\ndid want to say that I otherwise think this is a reasonable analysis.\n\nIn fact, calling the option imap.thunderbird-fixed-html is arguably a\nbetter name.\n\nFinally, I know it's my patch, but for the record, I won't be hurt if\nit's round filed.  You can make a clean case that not taking\nit in leaves pressure on the joint dev communities to find a better \nsolution.\n\nBut the only better approach I can imagine is if Thunderbird were\nto respect a 'format=fixed' injected in a message body.  However,\nas I think about that, I believe a correct Thunderbird implementation\nof that would require having a per message setting for format.\nThe Thunderbird team is very reluctant to expose any UI on\nf=f (see https://bugzilla.mozilla.org/show_bug.cgi?id=86607),\nso having a per message UI element certainly sounds like a dead\nidea walking :-/.\n\nCheers,\n\nJeremy\n"},{"id":"104519","messageId":"499587F0.1010102@beonex.com","threadId":"17752","inReplyTo":"49957AAE.7070505@codeweavers.com","subject":"Re: [Virtual PATCH] Add an option to wrap a patch in 
 in git-imap-send which ironically results in a cleaner patch from Thunderbird.","fromName":"Ben Bucksch","fromEmail":"ben.bucksch.news@beonex.com","sentAt":"2009-02-13T14:47:12Z","receivedAt":"2009-02-13T14:47:12Z","isPatch":true,"sender":{"key":"ben.bucksch.news@beonex.com","avatar":null},"body":">\n> I do not think of a reason, why any sane user would\n> want to send a patch as HTML.\n\nThe patch is not sent as HTML. It is merely passed to the mailer as HTML.\nThe \"reason\" is that HTML allows more information: It allows to separate \nhuman language text from preformatted text / source code.\n\nHuman language text follows other rules in some (I'll call them \"more \ncapable\", to be just as advocating) mailers than others: text flow / \nwrapping, link and quote recognition etc.pp. all make sense for human \nlanguage text / normal emails, but not for source code. Plain text is \ninherently limited in which information it can convey (no links, no \nquotes, no flow etc.pp.).\n\nFor more information, see the long email thread that preceeded. I don't \nfeel like repeating it.\n\n> This configuration variable sounds more\n> like \"imap.forceThunderbirdToSendNonFlowedTextByExploitingItsBug\" than\n> \"imap.html\", in other words.\n\nI agree that \"html\" is not a good wording, given the immediate disgust \nthat it invokes with many people in the community. (Which is partially \nwarranted, and partially irrational.)\n\nI'd propose a less inflammatory wording (and posts):\nimap.preformatted\nimap.thunderbird\n(The first is better, because other mailers might have the same problem, \nnow or in the future, and might benefit from the same workaround).\n\n> What worries me the most is if there is any guarantee that this bug you\n> are exploiting\n\nFWIW, it's not a bug that he's exploiting.\nmailto:foo@example.com?subject=\"\"&html-body=\"\" is a feature (not sure if \ndocumented).\n\n> _will not be fixed_ in future versions of Thunderbird.\n\nWhat you see is not a bug in Thunderbird.\n\n> I see your patch deals only with ampersand, less-than, greater-than and\n> dquot. Do you know if this is enough\n\nYes, this is enough to escape literals in HTML code.\n\n> or would letters outside US-ASCII\n> need to be expressed in ampersand-hash \"character reference\" notation?\n\nIf so, this this was a bug before and after the patch. What matters for \nnon-ascii is the charset, and that's the same problem for plaintext and \nHTML. You'll just have to set the right charset header, and I think he \ndoes that.\n"},{"id":"104534","messageId":"7v4oyy9qhw.fsf@gitster.siamese.dyndns.org","threadId":"17752","inReplyTo":"49955860.80504@drmicha.warpmail.net","subject":"Re: [Virtual PATCH] Add an option to wrap a patch in 
 in git-imap-send which ironically results in a cleaner patch from Thunderbird.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-13T17:49:15Z","receivedAt":"2009-02-13T17:49:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber  writes:\n\n>> What worries me the most is if there is any guarantee that this bug you\n>> are exploiting to force it to send a patch in the common denominator\n>> format _will not be fixed_ in future versions of Thunderbird.\n>\n> It's not a bug, it's a feature ;)\n>\n> In fact it really is: preformatted text in HTML (
) is by definition\n> left alone. Now, when you are about to send an HTML mail TB asks you\n> what to do (or takes a choice from preferences/addressbook): send as\n> HTML, as text or both.\n\nOk, \"TB asks you what to do and you choose 'text-only'\" is the part I\nmissed.  In that case, I'd agree it definitely is a feature not to use\nflowed to convert that 
..
 to a plain text.  Thanks for an\nexplanation.\n\n>> I see your patch deals only with ampersand, less-than, greater-than and\n>> dquot.  Do you know if this is enough, or would letters outside US-ASCII\n>> need to be expressed in ampersand-hash \"character reference\" notation?\n>\n> According to Ben of Mozilla fame this is enough for special characters.\n> I don't know about UTF-8, though. Usually, TB recognizes the proper\n> encoding.\n\nYeah, anything outside US-ASCII.  That was what I was wondering about.\n"}]}