Re: [PATCH 1/2] mailinfo: support rfc3676 (format=flowed) text/plain messages

I really do not like this.

format=flowed instructs the receivers MUA that it is Ok to reflow the text when the message is presented to the user. That is exactly what we do _NOT_ want to happen to patches. Your implementation may cleanly salvage what the sender intended to send, but salvaging when applying the patch is too late.

You review the patch, decide to apply or reject, and then finally apply. Unmangling of corrupt contents should be done before you review, not before you apply.

We have similar hacks to clean-up MIME attachments and CTE. They are useful when your mailpath is not clean and can corrupt contents even if you try to send it as text/plain in-line patch as a fallback measure to ensure the contents not to get corrupted. format=flowed is completely opposite --- you are giving your and recipients MUA freedom to reflow the text, but there is no valid reason to allow that when sending patches.

We do not even encourage MIME attachments and ask senders to try sending uncorrupt patch in-line, _even though_ MIME attachments is a way to try harder not to corrupt the payload. Why should we encourage format=flowed which is meant to do the opposite (i.e. we do not care about the exact content, we care more about how better the paragraph looks and easier to read on screens with different width)?

The format is not meant for the exact transmission of text (like "patch") but more for paragraphed prose that can be re-fit on narrower display like phones. Section 5. even goes to say "Hand-aligned text, such as ASCII tables or art, source code, etc., SHOULD be sent as fixed, not flowed lines."

Side note. I did not look at the patch very carefully, but can you salvage a deleted text in the patch that removes a line that consists of "- " (minus followed by a single space and then end-of-line), or any deleted or added text that ends with a SP without making them misinterpreted as "flowed" line for that matter?

I even suspect that the sending MUA client may misbehave for such a patch line. In fact, doesn't section 4.2 say "a generating agant should trim spaces before user-inserted hard line breaks."? It implies to me that you cannot have a fixed line that ends with SP.

So just reject the patch when somebody sends you format=flowed and ask them to re-send without =flowed, and the world will be a much better place.