Google should sent plain text mail with format=flowed (<a href="http://www.ietf.org/rfc/rfc2646.txt" rel="nofollow">http://www.ietf.org/rfc/rfc2646.txt</a>) as that would fix the issue for both very old clients which profit from the hard line breaks while still providing word wrapping on mobile clients.<p>It's ok if they don't support it when displaying mail, but by just setting that flag on sending, people with good clients will get the best possible experience
While I don't agree with Gmail automatically inserting linebreaks, 78 is basically <i>the</i> convention for plaintext email (and mailing lists often enforce this rule), so I do keep my lines within 80 characters and don't like it when others send everything on one line. The same applies to plaintext files, e.g. READMEs and related documentation, so I don't see why it should be any different for email. If you want to do something more fancy, use HTML instead.<p>The other annoyance I have is with email clients that display plaintext emails in proportional font, which mangles ASCII art diagrams and nicely-aligned tables/columns. The ones that attempt to "rejoin" lines and re-word-wrap also make a similar mess.
This misses the most annoying part of the line wrapping which is how it interacts with GMail's "Undo Send" feature. If you notice an error in your email and click Undo, they bring you back to the compose mode with the hard newlines still inserted.<p>If you edit the email and send, they now add more hard newlines for where the new line endings are and you end up with a mix of tiny lines and normal lines looking like your email is written in free verse.
This was a problem for me when I had to parse incoming emails. The solution I came up with was to ignore the text/plain part and instead strip all HTML from the text/html part, leaving you with the original text without all of the added newlines.<p>I wrote about this here: <a href="http://adamlafave.com/email-parsing-dont-parse-text-plain/" rel="nofollow">http://adamlafave.com/email-parsing-dont-parse-text-plain/</a>
Yes, plain text e-mail in Gmail is awful, absolutely unusable, fact recognised by many people, e.g. the Linux kernel people[1].<p>However, this article is hilariously bad, promotes bad practice concentrating on completely irrelevant issues and offering bad advice. Wrapped text is <i>good</i>, this has been talked to death so I won't repeat it here. Beside being bad style is general, non-wrapped e-mails are very strongly correlated to bad messages. If someone posts non-wrapped e-mails, or worse, HTML on a mailing list it's a very strong cue that person doesn't know what he's talking about, so it's a great way to ignore useless e-mails.<p>Gmail is bad because you can't turn wrapping off. On by default is a great default, it's just awful you can't turn it off when posting code or diffs.<p>Even worse, Gmails started converting tabs to spaces, and eliding leading indentation completely making it absolutely useless as a patch delivery mechanism. The new age auto-reflow stuff also interferes with this.<p>[1] <a href="https://www.kernel.org/doc/Documentation/email-clients.txt" rel="nofollow">https://www.kernel.org/doc/Documentation/email-clients.txt</a>
That “solution” won't help at all. 78 limit is about the client UI and its inability to wrap[1] and the lines still will be longer than 78 chars after decoding. (How and why exactly this matters in 2014 is another story.)<p>[1] <a href="http://tools.ietf.org/html/rfc2822#section-2.1.1" rel="nofollow">http://tools.ietf.org/html/rfc2822#section-2.1.1</a>
This post made me remember something: with the mail client which is built-in into Windows Phone, it's impossible to send plain text mails, even when you use Gmail.<p>And, on top of that, the mails are sent with the Calibri font. (Sorry for the off-topic)
The author hasn't made a case for why he needs to send plain text emails.<p>Every mail client - including text mode ones like Pine - supports HTML formatted emails, even if they end up displaying them without formatting.
The point of the convention is making the text fit on a 80-character fixed-with screen. QP-encoding the text won't solve that problem, as it will only create a very long line that is encoded in a way that has literal line breaks into it, which isn't the point.<p>What should be done, I believe, is that e-mail _clients_ should detect the 78-character convention and rejoin the lines into paragraphs if they think it would be best.<p>What Gmail does when sending mail is right, and the alternative view is that this convention should be dead and they should just throw it away and send very long lines.