LWN: Comments on "Re: [PATCH -mm] 1/2: MMCONFIG: validate against ACPI motherboard resources"

[PATCH]format=flowed

foom — Fri, 26 Mar 2010 14:05:26 +0000

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.

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

[PATCH]format=flowed

jschrod — Thu, 25 Mar 2010 23:52:17 +0000

> [about:config] then set mailnews.send_plaintext_flowed [to] false.

Thanks, thanks, thanks!

There are some client environments where I have to use Thunderbird. Now I can make them behave a bit better.

Offlineimap?

stevem — Thu, 28 Jun 2007 17:43:38 +0000

Yup, offlineimap rocks. And so does mairix, which you mention too. They make up a nice combination of tools to make imap mail Just Work. I should really finish writing up details of my mail system too.

KMail ate my hamster

pointwood — Thu, 21 Jun 2007 09:51:33 +0000

In regards to Kmail, this might be interesting: http://dot.kde.org/1182269390/

[PATCH]format=flowed

slamb — Fri, 15 Jun 2007 21:50:13 +0000

I don't get this either, but sometimes you have to let the wookie win. git users are very insistent on a particular format (see git's own Documentation/SubmittingPatches), and they merge enough patches that they don't want to mess around with figuring out your format. Whether their format is right or wrong, the consistency makes sense.

However, you may be able to just use git send-email when sending patches to these people, rather than alter your MUA's settings. format=flowed does serve a purpose, even if some people don't like the details of how it is done.

Offlineimap?

xoddam — Wed, 13 Jun 2007 02:47:41 +0000

Thankyou!

Offlineimap?

dmarti — Tue, 12 Jun 2007 22:31:50 +0000

If you like a mailer, but don't like its IMAP support, there's always offlineimap. (how I use it)

KMail ate my hamster

landley — Tue, 12 Jun 2007 01:59:50 +0000

No, IMAP is definitely kmail's kryptonite. I remember the time I told it
to download my email IMAP and it attempted to index my home directory as a
mail folder. (I have no idea WHY, but it did. Much "kill -9" ensued.)

Pop sort of worked, for definitions of "sort of" that didn't really make
it worth setting up pop (no encryption of any kind, if I recall).

These days I do all the network stuff through ssh tunneling. I do
something approximately this gross to download mail (as a prefetch script
to get a local mbox):
http://landley.net/code/filchmail

And for sending, an ssh tunnel to my mail server so sending email to
127.0.0.1:25 becomes a locally originating email on the mail server.

Basically, if Kmail never touches the network, it's a really nice mail
gui. And pop sort of worked last time I tried, with no security. But
don't try to use IMAP with it. There be dragons there.

Re: [PATCH -mm] 1/2: MMCONFIG: validate against ACPI motherboard resources

dirtyepic — Fri, 08 Jun 2007 02:32:41 +0000

Well, it's been long enough since the last time to forget what I didn't like, so I guess it's time to try it again.

KMail ate my hamster

xoddam — Fri, 08 Jun 2007 01:46:11 +0000

I tried KMail and it ate my IMAP folders.

Admittedly it was a build in Debian testing, about two years
back, so I'm not complaining too loudly, but I was burned
nevertheless and haven't used it much since.

To my shame I never reported the bug. I couldn't reproduce it.

[PATCH]format=flowed

xoddam — Fri, 08 Jun 2007 01:13:50 +0000

> It is an explicit attribute on the text/plain mime type.
> It doesn't require a fixed display width.

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

> (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
the aesthetic consequences of unreversed space-stuffing
are minimal, this is not expected to be a significant problem."

Programs parse email. Email messages can contain structured
text where leading white-space is significant, to human and
mechanical readers. Space stuffing stuffs it up. This *is*
a significant problem.

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

The problem (with Mozilla Mail aka Thuderbird) is that
*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.

FYI (or rather for the information of people who don't
like this behaviour), you *can* turn off format=flowed
for all outgoing mail:

Tools -> Options -> Advanced -> Config Editor

then set mailnews.send_plaintext_flowed false.

Unfortunately you can't turn it off easily per-message
while composing.

I have no problem with mime attachments for the purpose
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.

I have no problem with format=flowed for text which
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.

> What are you using as a client, "/usr/bin/mail"?

No, Thunderbird. Outlook. Evolution. KMail. Various
Web mail services. Piping emails to patch.

Thunderbird is admittedly the worst of them, and maybe
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

bronson — Thu, 07 Jun 2007 22:18:42 +0000

Amen to this. I've long since given up on the 3 big fights:
- Plain, ASCII text only. No HTML!
- Inline all text. Avoid MIME!
- No top posting!

Most people at my company top-post, and it does make sense when dashing off a quick reply.

It only took a decade, but MIME is pretty much universally supported.

And, finally, I receive email both on my 1920x1200 workstation and on my 320x240 handheld... There is no way for plain text to appear properly formatted on each screen whereas simple HTML works great.

So, I agree. I also send all patches as attachments. If the receiver's client won't show it, the receiver should use a different client.

[PATCH]format=flowed

foom — Thu, 07 Jun 2007 19:27:37 +0000

It's pretty ironic that my comments in this discussion are nearly unreadable in my RSS reader,
because LWN uses the HTML textarea wrap="physical" cols="75", and thus my browser is
hard-wrapping the comment text to 75 columns.

Sigh.

[PATCH]format=flowed

foom — Thu, 07 Jun 2007 17:59:05 +0000

> 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"?

Re: [PATCH -mm] 1/2: MMCONFIG: validate against ACPI motherboard resources

jospoortvliet — Thu, 07 Jun 2007 15:56:11 +0000

I'm pretty happy with KMail. You can use the keyboard to control it, it
has all the features I want, and is pretty easy to use. Tried it?

[PATCH]format=flowed

DonDiego — Thu, 07 Jun 2007 14:36:31 +0000

Not if the patch is flagged as text/plain, text/x-diff or text/x-patch. Your mail client can then quote it inline for you in replies.

If people send patches marked as binaries, mutt allows you to change the mime-type on the fly. I'm soooo in love with this feature ...

[PATCH]format=flowed

dw — Thu, 07 Jun 2007 14:04:21 +0000

I guess I've never seen this problem because I've been using MIME for embedding objects in mail since the dawn of my time. This is only a pseudo-troll, I know people dislike MIME but to me it seems a good pragmatic choice, since I'd imagine well over half of all e-mail uses it these days.

[PATCH]format=flowed

ekj — Thu, 07 Jun 2007 11:14:27 +0000

Also, often people reply to a patch with inline comments to stuff in it, which requires extra steps to do if the patch is an attachment.

[PATCH]format=flowed

xoddam — Thu, 07 Jun 2007 10:31:58 +0000

> No, _not_ using format=flowed wreaks havoc upon structured text.

The purpose of format=flowed is to let some paragraphs be
re-wrapped for narrow displays. The intention was that
anything other than a wrappable paragraph would be a
fixed text line and be treated like plain text.

But the inventors in their wisdom decided to fix other
things that also weren't broken (like wrapping of paragraphs
quoted with ">"), and invented "space stuffing":

"On reception, if the first character of a line is a space,
it is logically deleted."

"On generation, any unquoted lines which start with ">", and any
lines which start with a space or "From " MUST be space-stuffed.
Other lines MAY be space-stuffed as desired."

( from http://www.ietf.org/rfc/rfc3676.txt )

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.

> assume that the receiver also uses a client that
> wasn't written in the dark ages, and thus knows
> about the format=flowed parameter.

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

As long as anyone on a list is using an MUA which either (a) does
format=flowed *wrong*, like Thunderbird (and many other graphical
mail clients), or (b) doesn't do format=flowed at all, it makes
sense to deprecate it.

> lots of people on OSS mailing lists use clients that don't deal
> with attachments very well either (I guess?), so those are also
> disfavored...

I think the preference for in-line patches is so that they can be
read in-line, and so that the patch and accompanying message can
be saved together as a plain text file which works with 'patch'.
Attachments have an annoying habit of getting silently encoded as
quoted-printable or base64 -- which is almost as annoying as
format=flowed.

The habit of piping raw email messages to patch is compelling.
If format=flowed were implemented sufficiently consistently that
leading spaces were preserved across all MUAs which supported
it, there would be a compelling reason for 'patch' itself to
recognise the format=flowed line and parse the text accordingly.

As long as popular MUAs do it wrong, there is no point trying
to support it at all.

[PATCH]format=flowed

foom — Thu, 07 Jun 2007 07:37:45 +0000

No, _not_ using format=flowed wreaks havoc upon structured text. Email is limited to 80
characters in a lines by convention, and must be fewer than 997. If your code is wider than that,
the mail client should or must insert a linebreak in it. Without format=flowed, there is no way for
the receiver to distinguish the real linebreaks from the ones inserted by the client.

However, with format=flowed, the receiver knows which linebreaks were inserted artificially by
the sending mail client, and which were part of the actual content.

Having the unwrapping work properly does assume that the receiver also uses a client that
wasn't written in the dark ages, and thus knows about the format=flowed parameter. One would
think that would be a safe assumption by now.

Of course, the best solution to attaching a patch to your email such that client won't mangle
them in any way is to use these things called (funnily enough) "attachments". But it seems that
lots of people on OSS mailing lists use clients that don't deal with attachments very well either (I
guess?), so those are also disfavored...

[PATCH]format=flowed

xoddam — Thu, 07 Jun 2007 07:09:18 +0000

> With regards to format=flowed, what's wrong with it?

It wreaks havoc upon any structured text where line breaks are
significant. In particular, it mangles patches.

Re: [PATCH -mm] 1/2: MMCONFIG: validate against ACPI motherboard resources

dw — Thu, 07 Jun 2007 04:14:20 +0000

I lived with mutt for years very happily, and before and after that Mozilla and Thunderbird, and very recently, after an entire year of having coworkers tell me it's the right thing to do, Gmail (they were right; I spend 1/10th the time on mail compared to previous).

With regards to format=flowed, what's wrong with it? If your MUA ignores that parameter then it should still wrap at your terminal width, and if that isn't good enough, then you need to update your definition of compatibility to not include "first generation teletype devices." ;)

Re: [PATCH -mm] 1/2: MMCONFIG: validate against ACPI motherboard resources

dirtyepic — Thu, 07 Jun 2007 04:04:32 +0000

I'm convinced there's some contest to see who can make the worst graphical mail client for Linux. I'm not sure what the prize is, or who's winning, but the entries so far are horrific.

Amen. I've yet to find a GUI mail program i don't want to throw through a wood chipper a half dozen times. Choosing a client seems to be an exercise in finding the one whose broken behaviour annoys you the least.