In the 1990s a really nice feature was added to MIME text/plain, format=flowed which allows text to be re-wrapped without wrecking its legibility, even when the message mixes prose (reflowable) and code (not), even when it includes quoted excerpts from previous messages.
It never got much traction because Microsoft refused to implement it.
Most of the problems with email are due to Microsoft doing their own thing badly, for example the shitforbrains HTML renderer used by Outlook and the appallingly bad text/plain alternative parts that it produces. Apple Mail, by contrast, does a much nicer job.
The upshot is that there usually isn’t enough information in the message for a mail reader to adjust the formatting without mangling it irreparably, especially messages on developer-oriented mailing lists that mix prose, code, diffs, etc. So senders, even if they have good mail clients, should format their messages nicely, so that they don’t rely on the contents of Microsoft’s can of worms.
The correct thing to do is to configure mailing lists to reject email from Outlook (which, conveniently, puts some headers in to make this easy) and ask people to use a mail client instead.
A couple of years after I started using email in the ‘90s, people complained that MS Outlook (and its little brother, Microsoft Mail and News, which eventually became Outlook Express) couldn’t quote replies properly and encouraged top posting. People have been complaining about this for 30 years and Outlook still can’t get it right. At some point, you just have to say ‘sorry, you’ve had three decades to fix the basic bugs, you don’t get another chance’.
When I first got a job that required the use of Outlook, I found it was a truly awful piece of software. With a colleague’s help, I wrote a small VB script to create plain-text replies with proper quoting (and the cursor in the right place, after the quoted text). I don’t really understand VB and have no desire to learn it, but it seemed to do the job.
However, in the decade since, it has become a lost cause. When you are participating in a long e-mail thread, in which everyone else is top posting and quoting the entire thread every time, a properly-formatted reply just confuses things. I eventually gave up. When at work, I do as the workers do. When at home, I follow the netiquette guide that Demon Internet gave me in 1993.
This does not really answer the question @habibalamin asked.
Every modern mail reader I’m aware of can now word-wrap long lines in text/plain emails. (If an individual sends me a mail which is hard wrapped, I will, of course, as a matter of courtesy, hard wrap my reply, because presumably they are using an antediluvian mail program which does not know word wrap.)
Why should we continue caring about a 72/80-column limit at all in email? In my view, format=flowed is mostly an historical relic – useful for those mail readers that can’t do wrapping themselves, but these are few and far between. Anyone who has a mail reader without word wrap should fix it. But I’d be interested to hear why people think hard wrapping is still relevant.
Technically, it (kind of) does answer the question as far as I can see, though the answer is not very satisfactory (not @fanf’s fault). In fact, I’m on the verge of anger now. It gives the historical reasons why soft wrap never caught on in certain communities, but if this is still the reason they mandate hard wrap today, I find that inexcusable. There better be more to the story, because this is ridiculous.
First of all, you can hard wrap code at 72 columns in an email without hard wrapping prose. Literally every application which displays text soft wraps if a line is too long (okay, code can be configured to have the overflow off to the side where you scroll but I use soft wrap even in my code editor because it’s easy to spot, and I even turn my gutter off, so if email clients just soft wrapped code, it would still be better than this mess).
While we can support the source text customising aspects of how the soft wrap behaves and other minor improvements, it looks absolutely fine even on the most basic soft wrap behaviour; what doesn’t is hard wrapped text on mobile devices today, for example, or even on normal desktop mail clients that refuse to reflow text from certain sources.
As for code, are we supposed to imagine that the types of people who congregate in these mailing lists, when they’re looking at code in their mail client and it soft wraps (without some easy way to differentiate soft and hard wraps like their code editor might have), they struggle to discern what might be a soft wrap and what might be actual code formatting?
Isn’t it time they accept that the medium they’re working with is inadequate, and instead of mandating hard wrap, start mandating that people use sensible mail clients? Or mandate attaching code files (and the client can even try to embed source code attachments or allow them to easily be viewed in a tap/click/keypress, with easy format recognition/highlighting to boot)? Or, as I mentioned before, only mandate hard wrapping at a sub-80 column boundary for code, and not prose? I’m sure there’s another dozen ideas one could imagine, and I struggle to see how any of them could be worse without deliberately aiming to that end.
I’m willing to hear problems with any of the above ideas, but there still must be a better solution.
Can someone explain this etiquette to me. I’ve never understood it; why doesn’t the recipient’s client simply automatically wrap text?
There’s a long sordid history.
In the 1990s a really nice feature was added to MIME text/plain, format=flowed which allows text to be re-wrapped without wrecking its legibility, even when the message mixes prose (reflowable) and code (not), even when it includes quoted excerpts from previous messages.
It never got much traction because Microsoft refused to implement it.
Most of the problems with email are due to Microsoft doing their own thing badly, for example the shitforbrains HTML renderer used by Outlook and the appallingly bad text/plain alternative parts that it produces. Apple Mail, by contrast, does a much nicer job.
The upshot is that there usually isn’t enough information in the message for a mail reader to adjust the formatting without mangling it irreparably, especially messages on developer-oriented mailing lists that mix prose, code, diffs, etc. So senders, even if they have good mail clients, should format their messages nicely, so that they don’t rely on the contents of Microsoft’s can of worms.
The correct thing to do is to configure mailing lists to reject email from Outlook (which, conveniently, puts some headers in to make this easy) and ask people to use a mail client instead.
A couple of years after I started using email in the ‘90s, people complained that MS Outlook (and its little brother, Microsoft Mail and News, which eventually became Outlook Express) couldn’t quote replies properly and encouraged top posting. People have been complaining about this for 30 years and Outlook still can’t get it right. At some point, you just have to say ‘sorry, you’ve had three decades to fix the basic bugs, you don’t get another chance’.
When I first got a job that required the use of Outlook, I found it was a truly awful piece of software. With a colleague’s help, I wrote a small VB script to create plain-text replies with proper quoting (and the cursor in the right place, after the quoted text). I don’t really understand VB and have no desire to learn it, but it seemed to do the job.
However, in the decade since, it has become a lost cause. When you are participating in a long e-mail thread, in which everyone else is top posting and quoting the entire thread every time, a properly-formatted reply just confuses things. I eventually gave up. When at work, I do as the workers do. When at home, I follow the netiquette guide that Demon Internet gave me in 1993.
This does not really answer the question @habibalamin asked.
Every modern mail reader I’m aware of can now word-wrap long lines in
text/plainemails. (If an individual sends me a mail which is hard wrapped, I will, of course, as a matter of courtesy, hard wrap my reply, because presumably they are using an antediluvian mail program which does not know word wrap.)Why should we continue caring about a 72/80-column limit at all in email? In my view,
format=flowedis mostly an historical relic – useful for those mail readers that can’t do wrapping themselves, but these are few and far between. Anyone who has a mail reader without word wrap should fix it. But I’d be interested to hear why people think hard wrapping is still relevant.Technically, it (kind of) does answer the question as far as I can see, though the answer is not very satisfactory (not @fanf’s fault). In fact, I’m on the verge of anger now. It gives the historical reasons why soft wrap never caught on in certain communities, but if this is still the reason they mandate hard wrap today, I find that inexcusable. There better be more to the story, because this is ridiculous.
First of all, you can hard wrap code at 72 columns in an email without hard wrapping prose. Literally every application which displays text soft wraps if a line is too long (okay, code can be configured to have the overflow off to the side where you scroll but I use soft wrap even in my code editor because it’s easy to spot, and I even turn my gutter off, so if email clients just soft wrapped code, it would still be better than this mess).
While we can support the source text customising aspects of how the soft wrap behaves and other minor improvements, it looks absolutely fine even on the most basic soft wrap behaviour; what doesn’t is hard wrapped text on mobile devices today, for example, or even on normal desktop mail clients that refuse to reflow text from certain sources.
As for code, are we supposed to imagine that the types of people who congregate in these mailing lists, when they’re looking at code in their mail client and it soft wraps (without some easy way to differentiate soft and hard wraps like their code editor might have), they struggle to discern what might be a soft wrap and what might be actual code formatting?
Isn’t it time they accept that the medium they’re working with is inadequate, and instead of mandating hard wrap, start mandating that people use sensible mail clients? Or mandate attaching code files (and the client can even try to embed source code attachments or allow them to easily be viewed in a tap/click/keypress, with easy format recognition/highlighting to boot)? Or, as I mentioned before, only mandate hard wrapping at a sub-80 column boundary for code, and not prose? I’m sure there’s another dozen ideas one could imagine, and I struggle to see how any of them could be worse without deliberately aiming to that end.
I’m willing to hear problems with any of the above ideas, but there still must be a better solution.
Unfortunately, neither does Mail.app.
I think Mail.app used to support format=flowed many years ago, but the feature was dropped because of interop problems with Outlook 🤬
It did. I don’t recall if I ever read an “official” statement on why they dropped it but interop problems with Outlook are the rumous I’ve heard, too.
I used this plugin at some point after that and it worked, but I don’t know if that’s the case today, I’m not on Apple hardware anymore.
I love format=flowed but it seems rare even in communities which are very far from outlook culturally (like Debian mailing lists)
oh this looks super handy thank you for sharing