…or use the 10-year-old RFC 3676 format=flowed (which, by the way, itself builds on the 15-year-old RFC 2646). Not sure how many mail clients support those RFCs though…

Notably, Outlook does the same, so that’s probably why Gmail does it as well.

You should be asking for format=flowed instead of Quoted-Printable.

Update: Oh, I now see that I should have reloaded to see Thomas Broyer already mentioned format=flowed. It is supported by Apple Mail. Lack thereof in other clients continues to irk me even though I abandoned Apple Mail years ago.

Would that cause it to screw up the formatting of any code in an email?

I wonder if their broken Reply-To support is also the result of a misinterpreted RFC… sigh

This would be nice as an advanced feature, but there is a valid argument against making it the default:

Studies have shown that reading lines of text within the 60-100 character width improves accuracy, speed and is less fatiguing than longer, or shorter lines.

Note this topic’s been out there for some time.

Bijan, please look at the example image from the smartphone. Did you notice how the lines breaks at odd places? The device can only show a limited number of characters, so it has to break the lines, but still breaks it at the place where Google has put the line breaks.

Bijan, the point of quoted-printable or format=flowed is the receiver’s mail app is free to wrap at any width. The easiest way to do this is to shrink the window to a size you find comfortable, but some mail apps provide more powerful ways.

Without quoted-printable or format=flowed, the mail app has to assume the line breaks have to go where the sender’s mail app put them.

I like the way it is, and I really prefer that over emails that have lines of 2000 characters.

If you don’t want the standard text-wrap, just don’t use the plain text mode. HTML mode solves that problem.

Guillermo: Many things require plain text emails, such as the Debian mailing lists. This seems to be standard for many mailing lists.

This doesn’t even mention 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. 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.

Well, your criticism of Google’s defect is perfectly valid, but your suggestion is just as broken as the current state of affairs.

The correct way to display a mail that’s not format=flowed is as-is (after MIME decoding), without any changes in line breaks. Reflowing of long lines in such a mail is essentially a defect in the MUA, and can be quite annoying for some uses (exceptions might apply if the line is too wide for the viewport, but the width of the viewport is something quite different from the optimal reading width, which should be used for paragraph wrapping). QP encoding does solve the “transmission of long lines via email” problem, but what you are transmitting is still a line, while what you want to transmit is a reflowable paragraph, which does not exist as such in “normal” plain text emails.

The only sane solution is format=flowed, as that explicitly allows reflowing for MUA capable of doing so, but still keeps the text readable in MUAs that don’t understand format=flowed by keeping the lines reasonably short, and also keeps the quoting intact for both reflowing and non-reflowing UAs.

I think a) insertion of \n should be an option the sender has, and b) reflowing lines should be an option the receiver has.

In particular, the smartphone app should give the user the option to reflow plain text. In fact, it should probably be the default.

Radu: No, the point of email is that it is an interoperable system, and encoding or decoding choices for the user to make are a sign of a design flaw and not a solution, as that would mean that users have to manually ensure that their choice matches the choice of the person they are communicating with. The sending MUA should encode the input in a way that conveys the meaning that the user intended according to the standard and the receiving MUA should decode the mail and display it so that it conveys what the mail means according to the standard, then everything would be fine.

There might be an argument for having smartphone MUAs automatically reflow plaintext emails if there isn’t enough space for 80 columns due to the lack of any unambiguous paragraph encoding in “normal” plaintext emails, as that was a use case not anticipated by the old standard. But it should come with an easily accessible toggle in case you get a mail where line breaks are significant.

foobar: I don’t care about how this is implemented, encoding/decoding mumbo-jumbo.

I like short lines. If Gmail would stop inserting \n, I would type them myself. I understand if other people dislike Gmail being proactive and editing their email, so I think those people should be able to ask Gmail not to do so.

On the receiving end, if you see funny lines on the screen you should be able to ask for a reflow. Whether Gmail inserts \n or not has nothing to do with whether my email looks funny: as I said, I'd be perfectly willing to include the newlines myself. That shouldn’t cause immeasurable pain to receivers with tiny smartphones.

Again: the sender should have control over what message gets sent. The receiver should have control over how the message is displayed. I’m talking about the message. I don’t care about how the message is encoded.

Radu: No, you are probably thinking about it at the wrong level of abstraction if you think about “inserting \ns”. That’s already part of the encoding process. The user enters text and splits it into paragraphs and possibly lines. That’s what needs to be encoded so that after it has been decoded at the other end, the user again sees those paragraphs and lines. What kinds of (control) characters are needed in order to make that happen in a backward compatible way with all kinds of recipients is a matter of the respective email standards and none of the user’s business.

Ultimately, it is somewhat of a confusion to say “The sender should have control over what message gets sent. The receiver should have control over how the message is displayed.”. The structure of the message is part of the message, in the sense that it can be semantically relevant, and as such has to be reproduced by the receiving MUA in order to not lose information. If the receiving user has to instruct the MUA how to decode the mail into paragraphs and/or lines, that’s a workaround for a broken encoding mechanism. The mail itself should indicate what is a praragraph and therefore can be reflowed and what is a line and therefore can not, without any need for user intervention.

I agree that the problem is that Gmail is editing the mail. They split a paragraph(!) that the user entered into a series of lines(!) and send that instead. If the user composes a paragraph, they need to encode a paragraph and not silently convert it to something else.

I too feel the same way. I wish everything was plain text.

They also mess up when plaintext emails use > for quoting or if they have inline attachments. Gmail just doesn’t play well with plaintext email, I’m afraid.

Tried bringing it up a few years ago but they didn’t really care to fix it: https://groups.google.com/a/googleproductforums.com/d/msg/gmail/-/jLE7_XtZR8oJ.

There’s a really simple solution for this, actually: stop using Gmail.

foobar: The right level of abstraction, when designing what the user should see, is to ignore all encoding/decoding. I understand that “inserting \n” isn’t quite “inserting \n”, but the result of broken encoding/encoding. That, however, is completely irrelevant to me as a user. What I see is that the message gets edited.

They split a paragraph(!) that the user entered into a series of lines(!) and send that instead.

Actually, they split a line into a series of lines. Plain text has no concept of paragraph. That’s where the problem lies, and that’s why the receiver should be able to choose when reflowing is done.

You seem to think that a paragraph is a long line. I, on the other hand, often use the convention that a paragraph is something separated by two or more newlines.

Um, they don’t need to implement QP encoding — they already do that, only for different things. I see it used for Unicode characters and for the space in a quoted -- signature separator. My guess was always that the cost of another configuration option is too high for them.

A few short points:

1. I agree with the solution from this post.
2. Although plain text has no notion of paragraph, it occurs to me while writing this that Markdown has. I would like a mail client with support for Markdown.
3. Eli, the post already mentions that QP is used in other places in Gmail.

Radu: The thing is that it’s phrased as a plea for using QP for plain text, which is supposedly easy since they already use it for HTML. What I’m saying is that it’s even easier than that — they are using QP encoding for text too, only it’s done after the text is reflowed. And since they’re using a conventional QP encoder, the only thing that they need to do is avoid that hard-reflow step, nothing else. IOW, it means that the reply that is listed under “Google’s justification” is bogus — they don’t need to do the under-78-chars thing since the QP step already does it.

(This is easy to verify: just sending out text with a long word shows that it’s QP-encoded fine.)

Mathias: That’s what I use. Gnus for reading mail, using Muse (which is like Markdown, but better IMHO) for formatting the resulting mails.

Radu:

First of all, plain text actually does have a concept of a paragraph, it’s just that the encoding is ambiguous. A paragraph break is encoded as two line breaks in a row, which can not reasonably be distinguished automatically from two genuine line breaks in a row, which happen to have the same encoding, as you essentially have to understand the surrounding natural language text in order to distinguish the two cases. I guess that that’s probably really what you meant, but the distinction is important if one doesn’t want to become confused. BTW, I don’t think of a paragraph as either a long line or something separated by two or more newlines, those are both details of possible encodings — a paragraph is an abstract object of reflowable text that is structurally separate from surrounding text.

Now, I agree that the process by which the editing occurs is somewhat irrelevant to you as a user. But it is really important for you as someone advocating a solution.

Now, when you say “Actually, they split a line into a series of lines”, you are still confusing levels of abstraction, precisely because that actually is not what the user sees, but rather a detail of the encoding process that you happen to know. You know that the text a user enters into a <textarea> in a browser where the browser automatically wraps it into lines for display will be transmitted to the server as a string without any control characters apart from line breaks in those positions where the user explicitly pressed enter. So, when you simply print that string to a (wide) console, it will appear as “a line”. That’s why you think of it as “a line”. But that’s already an encoding of the user’s input: the user doesn’t see that. The user sees a long-ish, auto-wrapped piece of text — and that, from the point of view of the user, is a paragraph. The user interprets it as a “unit of text that will be separated from surrounding units of text and reflowed for optimal viewing” — it walks like a paragraph, it quacks like a paragraph, so it is a paragraph. That the paragraph breaks are encoded as double-linebreaks in the HTTP message is not the level of abstraction that the user is working at (even though the UI may indeed be somewhat leaky there, unfortunately).

A line, by contrast, is an object that is expected to not be reflowed and to be layed out without any structural separation from surrounding lines. The user quite definitely does not expect what is wrapped in the <textarea> to be displayed as one long line without any breaks at the recipient — therefore, it can’t be a line.

And this distinction is not purely academic, but extremely important. A common use for lines is the embedding of code and log excerpts in an email. Code and log excerpts essentially become unreadable if you reflow them, and it’s much better to scroll horizontally than to have to read reflowed code. Any surrounding commentary is likely to be paragraph text, though, so it’s perfectly fine, and for narrow screens very advantageous, to reflow it for display.

And that’s why QP encoding is not a solution. QP encoding transforms long lines so that they can be transported through email. But they stay lines nonetheless. And that’s important. If you put a long line of code or log excerpts into an email, your MUA should encode it into shorter lines using QP encoding, but the recipient should just reverse the encoding and again display one long line. If the receiving MUA were to reflow long lines, that would mean reflowing code and log excerpts, which is terrible.

Also, if you have an extremely wide viewport, paragraph text probably should not be reflowed to fill the full width, but rather some optimal reading width. Code blocks, though, most definitely should use the full width to stay readable.

And not only is the distinction of lines and paragraphs important because both have their use cases, but also, the existing encoding standards for emails define how to encode either of them, and advocating for an encoding or decoding that deviates from those standards just causes more incompatibility and thus pain for the user, rather than solving the problem. You can not just make up what you intuitively consider nice encodings. You have to go by what the standards say, that’s the only way to have a reliably interoperable distributed system, because others might not have the same intuitions as you have, but others can read the same standards. And the standard does not say “a long QP encoded line should be reflowed after QP decoding”.

Mathias:

Aren’t you contradicting yourself here? I’m confused either way.

I don’t think so?! Even given your following question, I don’t see any contradiction, and also nothing that I’d see how to confuse for a contradiction, but I’ll just try to answer it, maybe that’ll clear things up anyhow ;-)

QP encoding makes it possible to encode the original message including the line breaks the author intended, so that it can be decoded into its original form. How is that problematic?

That’s not problematic at all, and exactly what QP encoding is for. But my point is that if you QP-encode a long line, and then decode it, all you have is a long line, not a paragraph, and you should usually not reflow lines, whether they came QP-encoded or not (and correspondingly, you should not send long lines, just because you can make them fit through SMTP by QP-encoding them, as they still stay long lines at the semantic level). QP encoding is orthogonal to paragraph encoding.

If you want to encode a paragraph rather than a line, you have to use either HTML’s <p> element (bad compatibility with many MUAs) or plain text with format=flowed (much better backward compatibility), or both in a multipart message, if you see any advantage in that. And if you do that right, you might actually not need any QP encoding at all anymore. A format=flowed encoded mail actually represents paragraphs but won’t have any long lines that need QP encoding in order to be transmitted reliably via email.

Are you saying what OS X Mail.app is doing (i.e. the proposed QP-based solution) is somehow a Bad Thing™?

If Mail.app encodes paragraphs (that is, pieces of text that behave like a paragraph when you write them in the program, with automatic wrapping according to viewport size and all that) as one long line which then is QP encoded for transport, that’s a Bad Thing™ ;-), yes.

Is that the same thing as Apple Mail? I’ve seen creative MIME structures from that one before (attachments attached to the HTML alternative in a multipart/alternative mail, so the plain text version apparently didn’t have any attachments at all), so I wouldn’t expect too much from that.

Ultimately, it all comes down to being able to properly support transport of both prose, which is best presented in a paragraph layout and is not sensitive to being reflowed, and fixed-structure text, such as code and log files, which easily become incomprehensible when reflowed and should be displayed as-is, even if that means horizontal scrolling (and maybe even more importantly needs to retain its structure even when it’s quoted in a reply, that’s also something many MUAs get wrong).

Just a small note in passing that GMail (both Web and Android app) apparently supports format=flowed (and even DelSp=Yes): I just received a spam that used that and GMail displayed it as expected (for the curious, I was checking the mail headers and stumbled on the Content-Type, which reminded me of this blog post).

Google does it the way that it does, because it is The Right Thing™. Plain text should mean plain text. I just wish they would use a monospaced font when you are composing a plain text email.

I have no problems with enabling other encodings that are less than full HTML mark-up, but they shouldn’t be called plain text, because they aren’t…

David: There is probably nothing wrong with the mail itself, but if they wanted to produce that output, they should at least make sure it corresponds to the line breaks in the user interface — the problem, IMO, is, that they are silently changing the user input.

If you are referring to format=flowed, that actually is plain text, which is exactly the reason why it is the right thing to use. Or more precisely, it encodes paragraphs in a way that is valid plain text, readable for a human reader just as any other plain text, but with additional information hidden in whitespace that can be used by an appropriately capable MUA to decode it into paragraphs for improved rendering.

I didn’t realize that the practice of 78/80 characters can be annoying to people reading mails on phones. Until now I’ve been deliberately doing it. I write my mails in Vim and my editor settings automatically make sure of that. I find long flowing lines annoying and hard to read. Then there are people who write mails in Emacs or Vim — see vmail. I’m pretty sure they prefer their mails to arrive in hard wrapped 78 character format.

The other thing I find particularly annoying is that Gmail doesn’t a monospace font. Not having a monospace font screws up all the ASCII formatting of my mails which looks particularly good in my editor.

Displaying 4-5 words on a line itself makes any text uncomfortable to read. Reading text on such screens is not a ‘normal’ way to read it. The small screen is a limitation, a handicap, and it should be treated as a special case. 78 characters is not an unreasonable length to have as a standard. The ability of the screen to display at least 78 characters a line is a case on its own. This could be a problem even on a 26″ monitor if you overdo the Ctrl + ' inside the browser. Having the paragraph flow on the entire width of a wide screen monitor does not feel “natural” to me. I find the reasonable line length essential when reading the text. Many websites enforce such length, including this one.

What you are arguing here is whether the text should have word-wrap as a property, or if this should be determined by the viewer program. Personally, I support this view from 2 years ago.

+1 on format=flowed. Viewers should determine how to wrap messages, including those on ultra-wide screens, for readability. Senders should preserve all natural language attributes, including where the author inserted hard breaks. Everything else should flow.

Surprisingly, the Gmail app on Android sends plain-text emails without inserting hard line breaks, so Google’s justification for inserting hard line breaks in the Gmail web client is pure bullshit.

I totally agree with you. I’m using GMail in the plain text mode. The autowrap feature works poorly in writing mails in Japanese. It only works properly in languages made of words and whitespaces, not in Japanese, Korean, Chinese, and so on.

Ryou: Well, modern Korean language has spaces (example text), so this does not pose a big problem for them. It’s us Chinese and Japanese users who are affected, especially when we compose text with spaces around foreign words.

I am comfortable with the textwidth=78 setting in Gmail. However, they have poor support for East-Asian such as Chinese and Japanese. When you send a plain text mail in CJK with Gmail, they will just break your line at spaces. Since there are few (or none at all) spaces in Chinese / Japanese, the results are merely unpredictable and annoying.

For example, a plain text mail like this (Chinese lorem ipsum):

親比臺到紙為不是標強他圖，家想新士兩孩商資兩轉入感雖企破一牛親水坐味險。中地望的語開覺行女統他外出地的股車改票些是化我意如後品軍馬到！最管最死題：都力草點我入好者她成的可受致、笑系呢白愛不大望日的：細卻好風，報經知得、兩懷供不灣帶作名線？好兒有後方地達應是綠著不女積人叫面死印活萬起究夠電……得邊國會母沒業曾主行並言中文？然負發人我的來險？課商能中愛……水專裡製果年二本心檢術起學中管！多下是中文國我包去羅們勢天我呢義知公上進了笑的花什學持見，畫校至片久首士，同型得這當快想失飯、出裡裡光很大今起我來兒問除的文學並重一問，可外工麼雄活。者們才示的？

There will be no line breaks at all, since there are no spaces in it.

In modern Chinese / Japanese, there ARE some spaces in the text, for example around foreign words. If I randomly insert three English words in the above text and send this in Gmail, I get this:

親比臺到紙為不是標強他圖，家想新士兩孩商資兩轉入感雖企破一牛親水坐味險。中地望的語開覺行女統他 Hello
外出地的股車改票些是化我意如後品軍馬到！最管最死題：都力草點我入好者她成的可受致、笑系呢白愛不大望日的：細卻好風，報經知得、兩懷供不灣帶作名線？好兒有後方地達應是綠著不女積人叫面死
World 印活萬起究夠電……得邊國會母沒業曾主行並言中文？然負發人我的來險？課商能中愛……水專裡製果年二本心檢術起學中管！多下是中文國我包去羅們勢天我呢義知公上進了笑的花什學持見，畫校至片久首士，同型得這當快想失飯、出裡裡光很大今起我來兒問除的文學
Test 並重一問，可外工麼雄活。者們才示的？

I get four hard breaks, with different line lengths. Why? Because Gmail only breaks at spaces. Since there are only six spaces in the above paragraph, Gmail only inserts line breaks next to them.

This is even worse than no breaks.

Quoted-Printable breaks any code or URLs that you insert into the text that hit the flow line. Don’t do it. It’s not plain text at that point, it’s gibberish.

+1 on format=flowed. My own pine newsreader could handle that, and I’m pleased to see that Gmail can display it. It just needs to generate it as well.

I hate that Gmail wraps text. No other email service does this, not even Microsoft’s. It makes replies to my messages from other people look like I add all these line breaks myself.

+1, needs fixing, for example for folks that want to use Gmail to email a source-code patch. Automatic insertion of line-breaks invalidates the patch.

I always send message as HTML, and the wrapping issue is also present. I use my account for business and it’s frustrating for clients to receive notices with line break all over and most often to such a degree that the message cannot be read by the recipient. When viewing the sent mail from my Gmail account, all looks fine. When I send the mail to myself and read in Outlook, it’s horrible. Can anyone answer on the point of HTML messages being broken up as well?

Really funny I actually found this blog post via search engine when I tried to find out how to TURN OFF quoted-printable encoding. That is, I want to have it disabled for Google Groups USENET. There are actually two kinds of google groups: there are the groups under direct administration by Google itself, and there are the classic (usenet) groups hosted by Google, but likewise provided through ISP's usenet accounts.

Usenet old-timers do not like quoted-printable AT ALL, as it has caused nothing but trouble over the years. That's way it is crazy enough that posting into Usenet from your Google Groups account will automatically invoke Q-P mode. (checked via 'View original message' option to see my message as sent to the news server internally).

It is not only “wrapping” and line breaks that Gmail inserts into your text.

Even if you select plain text, Gmail inserts more hidden characters at the beginning of lines too, and in other places, so that when you try to copy + paste out of an email and into another application you are inadvertently also copying hidden characters that break the other apps.

Maybe I missed it, but why do e-mails display only one character per line when I try to read them on my phone or iPad, but perfectly normal and readable when I open the exact same e-mail on my PC? Is there a setting that I can change to get rid of this really annoying display problem? Thanks!!!

I came to say the same as the first comment: just use format=flowed as Thunderbird does. Or better yet, user, switch to Thunderbird instead of waiting for Google to adopt best practices!

If the editor broke the lines while you are editing the plain-text email, then there would be no problem! You could see if there were orphaned words on lines and fix it before sending.

I also suffer daily from the very poor plain-text mail composition, specifically the lack of format=flowed, which was the major regression coming from Thunderbird. I am happy to read mail in Gmail, but there is no apparent option to use an external composition tool.

My Gmail suddenly started doing this! Unfortunately I noticed after I sent my cover letter to a recruiter. It looks ridiculous. How do I stop it from doing so? It’s not in plain text mode!

Hi Mathias,

I wish I had the access you have to Google. Years ago when I was checking my email on Firefox there was a small problem. Then it got fixed. Now that I’m using Chrome the problem is back… So it wasn't an AOL problem but a browser problem. It be nice if Google fixed it. It’s another wrap problem but not the one you described here. I expect my emails are sent in HTML.

When I learned to type I was told that there should be two spaces after the period aka a full stop in England. When it happens that a sentence ends at the edge of my screen the next line starts with a space rather than the first letter of the first word of the next sentence e.g.

I like to swim.
 Then I go eat
lunch.

Thank you if you feel like passing this along.

I can’t find the answer to this question ANYwhere on the Internet, so thought I’d just try this page. I can’t make paragraphs in Gmail most of the time. Sometimes the Enter/Return key works, and sometimes it doesn’t. I have to type everything in Word and cut and paste it into Gmail. What could possibly cause this? So appreciative of an answer!

Or do what many (most? older?) mail readers have done, and have the editor itself automatically wrap lines at 78 characters while composing, and make it visible immediately to the user. This could be an option, with a default of 78.

Federico: I am getting the same results in Thunderbird: it’s making extra carriage returns in plain text emails.

FastMail works the same way as Gmail in this regard. If you want your lines to wrap nicely, you have to use HTML. If you send in plain text, lines will be hard-wrapped automatically.

Concerning the Quoted-Printable encoding, they say that it “was designed to solve a different problem”, which is true, of course. The support for soft-wrapped lines was “a side effect”, which is true as well — and all we actually need.

But, they say, using that encoding to support longer lines without hard-wrapping is “not completely problem-free”: http://mailformat.dan.info/body/linelength.html

Late “anecdote,” the first version of that Gmail editor didn’t even include a plain text option and, from what I recall, it was due to many Googlers asking for it that it got added (though it seems likely there would have been many more people demanding plain text messages had the team shipped that Gmail update without such an option).

Personally I’m less frustrated with this wrapping issue (I barely notice it all, if it’s still around) than about lack of a plain text option in Android, and then the various ways Gmail encourages top-posting and makes adhering to proper mail etiquette difficult. There, I find myself filing an occasional request.