Hacker News Reader

I'm very sad about manual line wrapping too (since I love plain text otherwise), but unfortunately it's in the MIME standard.

> Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

Of course with HTML, your source code can adhere to this standard while still having arbitrarily long lines of text...

https://mailformat.dan.info/body/linelength.html

The RFC you quoted actually refers to line lengths within a MIME message as a whole (headers and body), and only after Content-Transfer-Encoding has been applied, not before.

In other words, your text parts can have lines of arbitrary line length, provided you encode them as QuotedPrintable or Base64 and set the Content-Transfer-Encoding header accordingly, which most email clients do.

Thanks for the correction!

It’s an outdated standard and a terrible idea nowadays, since it makes emails unreadable on mobile devices. I’d really love to use plain-text emails — hell, I use plain text for everything — but they’re sadly not a good idea today, unless you want your emails looking like crap on every mobile device.

The suggestion to use `format=flowed` doesn’t help, as the standard is ill-supported: https://fastmail.blog/2016/12/17/format-flowed/

I’ve researched the issue far and wide and the only way to have responsive, nicely wrapped emails is using HTML.

This is the one blemish (in my view) on fastmail's record. I love them otherwise.

I initially came to the same conclusion as you, but after receiving one too many badly quoted HTML emails (and after some lost hours unsuccessfully trying to understand how fastmail web, gmail, thunderbird and ios mail.app do HTML quoting (hint: they're all subtly different)), I decided to double-down on format=flowed.

The main arguments in the fastmail blog you reference are:

1. Lack of support

2. Lack of people sending/reading plain text email

3. HTML bloat is no longer a real concern

Then they make some implementation difficulty arguments

1. Implement an editor that supports only semantic blockquoting

2. Fix "embarrassing line wrap" due to clients that lack support

For the first 3 arguments, I would say that lack of support from other clients doesn't mean that a client shouldn't support it. I regularly posted to usenet with Thunderbird (which supports format=flowed) and had people respond to my posts with clients that didn't support that feature.

To them (and when viewing the message source), the messages still appeared to be hard-wrapped. When viewing the messages in Thunderbird, the parts I typed were softwrapped. "Embarrassing line wrap" simply did not happen (no matter many times a given piece of text was quoted). "Embarrassing line wrap" was only an issue because certain clients would further re-wrapped quoted text without taking the quote markers into account instead of just leaving it alone or properly re-wrapping it.

Text editors like emacs and vim have features that will easily re-wrap quoted email text. Thunderbird has a feature where you can highlight quoted text and press ctrl-r to rewrap it. So I don't really see how it's difficult to eliminate the "embarrassing line wrap" issue when there are open source programs out there that have the capability (for several decades now) to fix it.

And I think they're missing the point by saying that HTML bloat is no longer an issue. It's not the amount of text that's transferred; it's how readable it is in a client that doesn't support rendering that text. IOW, reading raw HTML is not that easy.

As for implementing an editor that only supports semantic block quoting, I think they're missing the point again. It should be the person who's composing the email who decides whether a particular section of text should be hard-wrapped (meaning no trailing whitespace at the end of each line). You could have a feature where you highlight the text you want hardwrapped and then use a key combination or context menu to apply that change. The rest of the text is assumed to be soft-wrapped and will have trailing whitespace at the end of each line unless that line followed by a blank line.

> If my window is small (maybe because I am using a small screen), the text is painful to read. And a non manually wrapped wrapped plain text is not wrapped at all in certain cases.

If the MUA (Mail User Agent) does not soft wrap text, then text without hard wraps is painful to read. This also applies to text that's not meant to be soft wrapped (source code, error message output, log messages, etc.).

There is an RFC [1] that addresses this issue by introducing a format= flowed option in the MIME headers.

[1] https://www.ietf.org/rfc/rfc3676.txt

Sadly f=f is not widely supported (Thunderbird is a notable client using it).

I’m pretty sure hard wrapping at 80(?) chars is part of one of the RFCs.

hard wrap at 72 characters seems pretty conservative

This will wrap badly on many phones in portrait mode. The only hard wrapping that will probably not break anyone's workflow for sure is 1.

The reason it's 72 characters is to allow for quoted text, which gets indented relative to the new text. That would allow a line in an email that's 72 characters long to still fit within 80 characters if it's prefixed with 8 quote characters. For example:

>>>>>>>>This line was 72 characters long, but is now 80 characters long instead.

    Still looks pretty
    bad on anything
    less
    than 72 characters
    because there's
    random
    newlines in the 
    middle of 
    paragraphs. 
    
    Content should be
    separated from
    presentation.

    Additionally 72
    characters implies
    monospace 
    fonts which have
    been shown to be 
    less
    readable.

> Content should be separated from presentation.

Not necessarily. There are times where text should not be wrapped (code snippets, error messages, or log output), but if text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown. This requires that the client supports that type of markup which isn't always the case.

There is an RFC[1] that describes the format=flowed option in the MIME headers that addresses the wrapping issue (where text that should be soft-wrapped should have trailing whitespace at the end of each line). That would work with email clients that support that feature and will still appear to be hard-wrapped to email clients that do not. So, unlike HTML or markdown, we don't require those who use clients that only support plain text to update their clients to support a new feature. We can use that feature in clients that support it and have a sensible fallback for clients that do not.

[1] https://www.ietf.org/rfc/rfc3676.txt

> If text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown

Precisely. HTML and markdown separate content from presentation, so content that should never be wrapped - like ```code``` or <blockquote>code</blockquote> is handled properly.

Yes, but that doesn't have a sensible fallback for clients that don't support html or markdown. format=flowed does have a sensible fallback.

>If my window is small (maybe because I am using a small screen), the text is painful to read.

If your screen is so small that it can't display 80 characters across then pretty much anything you look at it with is going to look odd. Any HTML formatting such as tables will also be painful to read.

Have you ever seen someone with poor eyesight use a smart phone?

You’re missing the point that anything longer than 80 chars is harder for the human. Ideally it should be 65.

That said, wrapping is better left to the mail client, and let the user adjust their window to suit. My chief gripe at this point is that some email clients (gmail anyway) will get confused by outsized inline images and wrap on them, even if that means letting text drift off the side of the screen!

I like big characters. I can be far from my screen to read, use a low brightness and never have tired eyes.

I just checked on my phone some random opened web page: with my settings (which are far from the default - I raise the DPI setting and the font size so I have small UI elements but big texts), it displays 45 characters per line on portrait mode. Actually the font size is a bit too high, but I don't really care as far as most web pages are readable. I'm fine with scrolling the occasional big HTML table, and will change the settings if this becomes annoying.

So, yes, sometimes, my screen displays less than 80 characters and is perfectly usable. And this fact is not really of my correspondent's business, whether they choose to manually wrap at 80 characters, 72 characters, 42 characters or some other arbitrary number of characters. Actually, nobody knows that apart from people who read this comment. I display text as I see fit (and this is totally an intended pun).