[PATCH]format=flowed
[PATCH]format=flowed
Posted Jun 7, 2007 17:59 UTC (Thu) by foom (subscriber, #14868)In reply to: [PATCH]format=flowed by xoddam
Parent article: Re: [PATCH -mm] 1/2: MMCONFIG: validate against ACPI motherboard resources
> If this 'flowed text' were a separate mime-type, and text was always converted to and from it
> consistently (which requires a given display width and an unambiguous way to distinguish
> wrappable paragraphs from "fixed lines"), there would be no problem. But it's also supposed
> to be plain text, and display (and parse!) the same as plain text. It doesn't, and it can't.
It is an explicit attribute on the text/plain mime type. It doesn't require a fixed display width. It is
unambiguously convertible back into the unwrapped form. It is not supposed to parse the same
as plain text. (where are you coming up with this?)
You aren't suppsed to randomly apply format=flowed rules to all incoming text. Just that which
explicitly states it was encoded using that scheme...
Prior to format=flowed, to send plaintext mail which round-trips paragraphs properly, the only
option was quoted-printable encoding. That worked and works great, but doesn't degrade very
well for people using crappy clients. With format=flowed, the emails roundtrip in useful clients,
and don't look completely terrible on lame clients. It is a total win.
> Knowing about it and implementing it *correctly* aren't quite the same.
>
> There are so many bugs persisting in eg. Thunderbird (follow
> links from https://bugzilla.mozilla.org/show_bug.cgi?id=168420)
> that when I use the same program as composer and reader,
> indentation is messed up *every time*.
Okay, I've never used Thunderbird. Maybe it's absolutely totally worthless at email, I can believe
that. But it having a defective implementation doesn't make the thing it implements bad. Apple
Mail composes plaintext mail which round-trips perfectly. It's really not that mysterious a
process, the rules are plainly spelled out in the RFC.
> Attachments have an annoying habit of getting silently encoded as
> quoted-printable or base64
Well, yeah...Any mail client worth its salt will decode q-p and base64 encodings before you ever
see them. What are you using as a client, "/usr/bin/mail"?
Posted Jun 7, 2007 19:27 UTC (Thu)
by foom (subscriber, #14868)
[Link]
Sigh.
Posted Jun 8, 2007 1:13 UTC (Fri)
by xoddam (subscriber, #2322)
[Link] (2 responses)
(I just meant you need a display width to render it)
> It is unambiguously convertible back into the unwrapped form.
Round-trips are broken in several MUAs.
> It is not supposed to parse the same as plain text.
Well alright, that wasn't a requirement. But it is supposed
> (where are you coming up with this?)
RFC 2646 and RFC 3676, which make a false assumption:
"Since lines which require space-stuffing rarely occur, and
Programs parse email. Email messages can contain structured
> You aren't suppsed to randomly apply format=flowed rules
The problem (with Mozilla Mail aka Thuderbird) is that
FYI (or rather for the information of people who don't
Tools -> Options -> Advanced -> Config Editor
then set mailnews.send_plaintext_flowed false.
Unfortunately you can't turn it off easily per-message
I have no problem with mime attachments for the purpose
I have no problem with format=flowed for text which
> What are you using as a client, "/usr/bin/mail"?
No, Thunderbird. Outlook. Evolution. KMail. Various
Thunderbird is admittedly the worst of them, and maybe
Posted Mar 25, 2010 23:52 UTC (Thu)
by jschrod (subscriber, #1646)
[Link]
Thanks, thanks, thanks!
There are some client environments where I have to use Thunderbird. Now I can make them behave a bit better.
Posted Mar 26, 2010 14:05 UTC (Fri)
by foom (subscriber, #14868)
[Link]
I don't really understand why anyone likes to do it the other way. Having it as an attachment
makes
it easier to extract (save the file, vs find the beginning and end of the patch and copy/paste), and
many mail-readers will display plaintext attachments inline, too...
Unfortunately, as of OSX 10.6.2, Apple Mail stopped sending format=flowed, and now always
sends MIME quoted-printable encoding (without any added line-breaks encoded), which of
course is a complete disaster, since mail-list archives are generally too stupid to do anything but
decode the quoted-printable...and it ends up all on a single line, with soft-wrapping disallowed.
:(
So you get things like:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-March/030...
It's pretty ironic that my comments in this discussion are nearly unreadable in my RSS reader, [PATCH]format=flowed
because LWN uses the HTML textarea wrap="physical" cols="75", and thus my browser is
hard-wrapping the comment text to 75 columns.
> It is an explicit attribute on the text/plain mime type.[PATCH]format=flowed
> It doesn't require a fixed display width.
to *display* the same as plain text in user agents which
do not support it. It doesn't. Moreover, it doesn't parse
the same.
the aesthetic consequences of unreversed space-stuffing
are minimal, this is not expected to be a significant problem."
text where leading white-space is significant, to human and
mechanical readers. Space stuffing stuffs it up. This *is*
a significant problem.
> to all incoming text. Just that which explicitly states
> it was encoded using that scheme...
*all* *outgoing* plain text mail is format=flowed,
whether or not you want your text to be parseable at
the other end. A further problem is that the users
mostly have no idea they're sending email which isn't
(quite) text/plain. It took me years to discover what
the problem was, and how to fix it. Literally.
like this behaviour), you *can* turn off format=flowed
for all outgoing mail:
while composing.
of sending files. But patches are supposed to be readable
by humans and by the patch program. They are often sent
for discussion to a mailing list.
is just paragraphs and non-indented lines. I have
not turned off the preference for *displaying* flowed
text. But as soon as whitespace (leading or trailing)
becomes significant, format=flowed ceases to be
appropriate. The obvious cases are patches, inline code
or pseudocode, ASCII art and "manually" indented
paragraphs such as outline lists.
Web mail services. Piping emails to patch.
the only one which consistently breaks round-trips. But
none of them give any indication that what they're sending
is not "fixed" text/plain; you have to dig deep into
preferences, FAQs and bug databases to learn the most basic
things about what is a very basic computing task.
[PATCH]format=flowed
I've been using format=flowed in my mail-reader for years (Apple Mail) -- and have not had the
problems you have. In my experience, the assumption in the RFC about space-stuffing not
causing a big problem is spot on. Maybe it's because when I have something like a patch, I
attach it to the mail instead of pasting it into the body.
[PATCH]format=flowed