10 ms·

Plain text wrapping in Gmail

171 points by daw___ 12y ago

mahouse 12y ago
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. And, on top of that, the mails are sent with the Calibri font. (Sorry for the off-topic)
- e12e 12y ago
  "My answers below, in red."
zorked 12y ago
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. 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. 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.
- mattdw 12y ago
  I disagree, because it's (far) easier to soft-wrap QP long lines than it is to unwrap hard-wrapped short lines. Hard-wrapping essentially causes a loss of information, by not distinguishing between user-inserted and program-inserted newlines. Any client program can wrap as appropriate (which is not always to 80 chars, but 80 chars would work as well as anything) with QP; the same is not true of hard-wrapped as gmail does it.
- marcosdumay 12y ago
  Once you insert all the line breaks, the email clients can not reliably reconstruct the original paragraphs anymore. Yes, the point of the convention is to make text fit on the 80 char terminal. Nowadays clients use extremely different viewer widths, thus it's an outdated recommendation, that should not be followed anymore.
- claudius 12y ago
  > 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. That’s what format=flowed allows. The sending client line-wraps long lines at 78-or-so characters and then indicates having done so by appending an extra space at the end of such lines. This way, clients can either (a) leave everything as-is, the trailing spaces won’t hurt or (b) rejoin the lines into one long paragraph. I would probably prefer the latter behaviour on a phone or screen with less than 80 characters, whereas on the desktop, I’d rather not be presented with lines running over the entire width of the screen. But really, this is pretty standard in mail clients… Edit: added quotation mark, sorry.
- mathias 12y ago
  The point of typing a message in a webmail UI and sending it is to deliver the exact message you entered to the recipient. Adding hard line breaks, effectively altering the original message, is not useful. Making text fit on a 80-character fixed-width screen is not something the email sender should do; the recipient’s email client should do it based on their preferences.
lelf 12y ago
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.) [1] http://tools.ietf.org/html/rfc2822#section-2.1.1 http://tools.ietf.org/html/rfc2822#section-2.1.1
- nailer 12y ago
  (you don't need to link to RFC2822 section 2.1.1, it's linked to in the article that you just read) I'm quite familiar with the 78 line break as a Unix user for the last 15 years, but Section 2.1.1 is RFC 2822 should never have been carried forward from RFC 822, where it was originally written decades ago: - There are many displays less than 78 characters wide. - There are many displays more than 78 characters wide. - Most apps that run on displays that are 78 characters wide can happily display paragraphs in their available width. The IETF is wrong. For that matter, I even wrote a Chrome extension to specifically fix reading IETF papers: https://github.com/mikemaccana/deneckbeard https://github.com/mikemaccana/deneckbeard
  - rakoo 12y ago
    To me the 78 line break is still relevant, not because my displays are small, but because wider texts are less readable.
    - nailer 12y ago
      That's a legitimate concern: 8-12 words per line was tested and found to be optimal some years ago in print, and the web since 2001, where it was called 'snake text' http://www.suck.com/daily/2001/01/15/ http://www.suck.com/daily/2001/01/15/. However a hard 78 character limit isn't exactly 8-12 characters, and hard broken lines will still look poor on small displays. Ultimately, email should be content only, and display handled on the display device.
      - sp332 12y ago
        The recipient client's limitations shouldn't limit me as a sender. If I want to include a long code sample, or some concrete poetry, gmail shouldn't step on my toes. I don't mind the current behavior being the default, but it should be settable.
pilif 12y ago
Google should sent plain text mail with format=flowed (http://www.ietf.org/rfc/rfc2646.txt http://www.ietf.org/rfc/rfc2646.txt) 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. 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
- zbowling 12y ago
  by old clients, that is pre-2000's era email clients. Why are we supporting ~15 year old email clients anyways?
  - pilif 12y ago
    Gmail doesn't support format=flowed, so from that perspective, it too is an old client. Last time I checked, one of the most widely used non-web clients also didn't support it (Outlook). But the good thing about format=flowed is that even if a client doesn't support it for display, it'll still look good (on desktops)
  - DanBC 12y ago
    Because there is no need not to. Email is ancient; it still works; it usually does not need round CSS corners nor bold HTML stuff. "Modern" clients gives you utter shit like WebTV and midi-file signatures.
    - Zecc 12y ago
      > midi-file signatures Seriously?! Is this a thing? Please tell me that was hyperbole.
      - bzbarsky 12y ago
        It's a thing. See http://www.ehow.com/how_4928010_add-music-yahoo-email-signature.html http://www.ehow.com/how_4928010_add-music-yahoo-email-signat... for example.
userbinator 12y ago
While I don't agree with Gmail automatically inserting linebreaks, 78 is basically the 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. 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.
- jgalt212 12y ago
  table preservation and subsequent extraction becomes complex when the tables are in a forwarded email and there's a quote prefix (e.g. '> ') which takes one or more line lengths above 78 and then somewhere along the chain single table rows will then be split into multiple lines. In these cases, it takes all the kings horses and all the kings men to put humpty dumpty back together again.
  - zAy0LfpBZLC8mAC 12y ago
    If a MUA breaks lines in quoted text (not to be confused with reflowing format=flowed!), that's a bug in the MUA. While email isn't trivial, it's not _that_ difficult either, if people cared.
- Ironlink 12y ago
  > 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. If you want to send me ASCII art, use HTML and CSS to specify the font required for display. My email client will default to a font which is pleasant to my eyes. It is ridiculous that my choice of default font should be confined by a tiny subset of email content, especially where the author knows ahead of time that this content is sensitive to the font it is displayed with.
  - 12y ago
4ad 12y ago
Yes, plain text e-mail in Gmail is awful, absolutely unusable, fact recognised by many people, e.g. the Linux kernel people[1]. However, this article is hilariously bad, promotes bad practice concentrating on completely irrelevant issues and offering bad advice. Wrapped text is good, 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. 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. 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. [1] https://www.kernel.org/doc/Documentation/email-clients.txt https://www.kernel.org/doc/Documentation/email-clients.txt
quasque 12y ago
The author hasn't made a case for why he needs to send plain text emails. Every mail client - including text mode ones like Pine - supports HTML formatted emails, even if they end up displaying them without formatting.
- ekmartin 12y ago
  A lot of mailing lists require you to send plain text emails, with the Linux Kernel being an example.
  - ZirconCode 12y ago
    you beat me to it by a minute ;)
  - TorKlingberg 12y ago
    Don't those mailing lists also require line wrapping?
    - 4ad 12y ago
      They require sensible line wrapping. Line wrapping text is good, even required for commit messages, but line wrapping git patches is obviously a catastrophe. On Gmail you can't turn wrapping off (and you can't send patches anyway as it elides leading indentation and changes tabs to spaces).
- ZirconCode 12y ago
  Many mailing lists only accept plaintext. It's a common standard in older communities (ex. linux).
  - quasque 12y ago
    Seems a rather archaic requirement to be imposing on one's users, but thanks for clarifying!
- Pacabel 12y ago
JetSpiegel 12y ago
It's not like you can't use a real email client. What's this obsession with web apps for everything? Use thunderbird, or k9 on android.
- koralatov 12y ago
  I've never seriously used anything except a real client for e-mail (ZIMACS, then Thunderbird, then Apple Mail, now mutt), and any time I have used a web-app for e-mail, the whole process is just frustrating. I'm especially surprised when I come across people who say they ``live in their Gmail'' and actually do live in the web-app.
  - JetSpiegel 12y ago
    The worse thing is totally different interfaces between different mail providers. It makes impossible to have multiple email addresses and manage them in a sane manner. Do you have any primers to use mutt? I really wanted a terminal-based alternative to Thunderbird in case I need to ssh from somewhere, or if I'm in a hurry, but the man page alone scares me.
    - zAy0LfpBZLC8mAC 12y ago
      Just start it? In the standard config, it has a help line that tells you about all the most common key bindings, I'd think it really isn't difficult to get started and look things up in the manual as needed. If you are not on a fully configured unix system with an MTA and local mail spool, the only thing you'll have to set up to get started should be the mail server config.
      - JetSpiegel 12y ago
        Yeah, I need to find the time to just roll with it.
partomniscient 12y ago
The problem with RFC2822 (as with all specifications) is that it failed to correctly predict this future (and ideally all other possible futures).
- zAy0LfpBZLC8mAC 12y ago
  The good thing about RFC822 (and by extension RFC2822) is that it is extremely flexible instead of trying to predict the future and in the process creating an unimplementable monster of mispredictions (cf. OSI networking stack). Even though the stack of email RFCs contains quite some cruft due to historic accidents, it's actually not as bad as you might think when looking at all the terrible mail software out there that seems to be written by people who don't even bother to read the RFCs (which seems to include google, after all).
  - partomniscient 12y ago
    I was being somewhat facetious, but you're correct. It's a balancing act of so many factors, many of which are beyond the originators control or realisation. Quite a while ago I considered trying to write an IMAP library for a language I used - after some brief research I concluded: that way lies madness.
bobbyi_settv 12y ago
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. 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.
Chinasol 12y ago
It's great to see the old 80-column punched card standard fossilised in these modern environments...
- XorNot 12y ago
  80 columns gives you 3 files side-by-side on a 1920 monitor.
  - skj 12y ago
    Surely that depends on more than just the number of columns and the number of pixels.
- wpietri 12y ago
  And my understanding is that we got punched cards of that size because they fit into the boxes and drawers for large-format US banknotes: http://en.wikipedia.org/wiki/Large-sized_note http://en.wikipedia.org/wiki/Large-sized_note Which in turn apparently goes back to taking a common paper size and cutting it into reasonably-sized pieces: http://ask.metafilter.com/262846/What-is-the-origin-of-the-dimensions-of-large-sized-US-dollar-bills http://ask.metafilter.com/262846/What-is-the-origin-of-the-d... So apparently one person lost to history said, "How big should it be? I don't know. Maybe about this big?" Centuries later, somebody at IBM said, "It looks like we could fit 80 columns on that. Good enough?"
  - kps 12y ago
    Hollerith cards originally had 45 columns.
- kps 12y ago
  Line length around 80 columns come from letter paper in a typewriter (via teleprinters) which in turn comes from book printing, where around 60–65 printed characters (plus blanks) were established as most readable centuries ago.
qwerta 12y ago
Why you just do not use different email client?
adamlafave 12y ago
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. I wrote about this here: http://adamlafave.com/email-parsing-dont-parse-text-plain/ http://adamlafave.com/email-parsing-dont-parse-text-plain/
zem 12y ago
i finally gave up and switched to sending html mail precisely because of this issue :(

171 points by daw___ 12y ago

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. And, on top of that, the mails are sent with the Calibri font. (Sorry for the off-topic)

e12e 12y ago
"My answers below, in red."

zorked 12y ago

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

mattdw 12y ago
I disagree, because it's (far) easier to soft-wrap QP long lines than it is to unwrap hard-wrapped short lines. Hard-wrapping essentially causes a loss of information, by not distinguishing between user-inserted and program-inserted newlines. Any client program can wrap as appropriate (which is not always to 80 chars, but 80 chars would work as well as anything) with QP; the same is not true of hard-wrapped as gmail does it.
marcosdumay 12y ago
Once you insert all the line breaks, the email clients can not reliably reconstruct the original paragraphs anymore. Yes, the point of the convention is to make text fit on the 80 char terminal. Nowadays clients use extremely different viewer widths, thus it's an outdated recommendation, that should not be followed anymore.
claudius 12y ago
> 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. That’s what format=flowed allows. The sending client line-wraps long lines at 78-or-so characters and then indicates having done so by appending an extra space at the end of such lines. This way, clients can either (a) leave everything as-is, the trailing spaces won’t hurt or (b) rejoin the lines into one long paragraph. I would probably prefer the latter behaviour on a phone or screen with less than 80 characters, whereas on the desktop, I’d rather not be presented with lines running over the entire width of the screen. But really, this is pretty standard in mail clients… Edit: added quotation mark, sorry.
mathias 12y ago
The point of typing a message in a webmail UI and sending it is to deliver the exact message you entered to the recipient. Adding hard line breaks, effectively altering the original message, is not useful. Making text fit on a 80-character fixed-width screen is not something the email sender should do; the recipient’s email client should do it based on their preferences.

lelf 12y ago

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.) [1] http://tools.ietf.org/html/rfc2822#section-2.1.1 http://tools.ietf.org/html/rfc2822#section-2.1.1

nailer 12y ago
(you don't need to link to RFC2822 section 2.1.1, it's linked to in the article that you just read) I'm quite familiar with the 78 line break as a Unix user for the last 15 years, but Section 2.1.1 is RFC 2822 should never have been carried forward from RFC 822, where it was originally written decades ago: - There are many displays less than 78 characters wide. - There are many displays more than 78 characters wide. - Most apps that run on displays that are 78 characters wide can happily display paragraphs in their available width. The IETF is wrong. For that matter, I even wrote a Chrome extension to specifically fix reading IETF papers: https://github.com/mikemaccana/deneckbeard https://github.com/mikemaccana/deneckbeard
- rakoo 12y ago
  To me the 78 line break is still relevant, not because my displays are small, but because wider texts are less readable.
  - nailer 12y ago
    That's a legitimate concern: 8-12 words per line was tested and found to be optimal some years ago in print, and the web since 2001, where it was called 'snake text' http://www.suck.com/daily/2001/01/15/ http://www.suck.com/daily/2001/01/15/. However a hard 78 character limit isn't exactly 8-12 characters, and hard broken lines will still look poor on small displays. Ultimately, email should be content only, and display handled on the display device.
    - sp332 12y ago
      The recipient client's limitations shouldn't limit me as a sender. If I want to include a long code sample, or some concrete poetry, gmail shouldn't step on my toes. I don't mind the current behavior being the default, but it should be settable.

pilif 12y ago

Google should sent plain text mail with format=flowed (http://www.ietf.org/rfc/rfc2646.txt http://www.ietf.org/rfc/rfc2646.txt) 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. 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

zbowling 12y ago
by old clients, that is pre-2000's era email clients. Why are we supporting ~15 year old email clients anyways?
- pilif 12y ago
  Gmail doesn't support format=flowed, so from that perspective, it too is an old client. Last time I checked, one of the most widely used non-web clients also didn't support it (Outlook). But the good thing about format=flowed is that even if a client doesn't support it for display, it'll still look good (on desktops)
- DanBC 12y ago
  Because there is no need not to. Email is ancient; it still works; it usually does not need round CSS corners nor bold HTML stuff. "Modern" clients gives you utter shit like WebTV and midi-file signatures.
  - Zecc 12y ago
    > midi-file signatures Seriously?! Is this a thing? Please tell me that was hyperbole.
    - bzbarsky 12y ago
      It's a thing. See http://www.ehow.com/how_4928010_add-music-yahoo-email-signature.html http://www.ehow.com/how_4928010_add-music-yahoo-email-signat... for example.

userbinator 12y ago

While I don't agree with Gmail automatically inserting linebreaks, 78 is basically the 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. 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.

jgalt212 12y ago
table preservation and subsequent extraction becomes complex when the tables are in a forwarded email and there's a quote prefix (e.g. '> ') which takes one or more line lengths above 78 and then somewhere along the chain single table rows will then be split into multiple lines. In these cases, it takes all the kings horses and all the kings men to put humpty dumpty back together again.
- zAy0LfpBZLC8mAC 12y ago
  If a MUA breaks lines in quoted text (not to be confused with reflowing format=flowed!), that's a bug in the MUA. While email isn't trivial, it's not _that_ difficult either, if people cared.
Ironlink 12y ago
> 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. If you want to send me ASCII art, use HTML and CSS to specify the font required for display. My email client will default to a font which is pleasant to my eyes. It is ridiculous that my choice of default font should be confined by a tiny subset of email content, especially where the author knows ahead of time that this content is sensitive to the font it is displayed with.
- 12y ago

4ad 12y ago

Yes, plain text e-mail in Gmail is awful, absolutely unusable, fact recognised by many people, e.g. the Linux kernel people[1]. However, this article is hilariously bad, promotes bad practice concentrating on completely irrelevant issues and offering bad advice. Wrapped text is good, 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. 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. 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. [1] https://www.kernel.org/doc/Documentation/email-clients.txt https://www.kernel.org/doc/Documentation/email-clients.txt

quasque 12y ago

The author hasn't made a case for why he needs to send plain text emails. Every mail client - including text mode ones like Pine - supports HTML formatted emails, even if they end up displaying them without formatting.

ekmartin 12y ago
A lot of mailing lists require you to send plain text emails, with the Linux Kernel being an example.
- ZirconCode 12y ago
  you beat me to it by a minute ;)
- TorKlingberg 12y ago
  Don't those mailing lists also require line wrapping?
  - 4ad 12y ago
    They require sensible line wrapping. Line wrapping text is good, even required for commit messages, but line wrapping git patches is obviously a catastrophe. On Gmail you can't turn wrapping off (and you can't send patches anyway as it elides leading indentation and changes tabs to spaces).
ZirconCode 12y ago
Many mailing lists only accept plaintext. It's a common standard in older communities (ex. linux).
- quasque 12y ago
  Seems a rather archaic requirement to be imposing on one's users, but thanks for clarifying!
Pacabel 12y ago

JetSpiegel 12y ago

It's not like you can't use a real email client. What's this obsession with web apps for everything? Use thunderbird, or k9 on android.

koralatov 12y ago
I've never seriously used anything except a real client for e-mail (ZIMACS, then Thunderbird, then Apple Mail, now mutt), and any time I have used a web-app for e-mail, the whole process is just frustrating. I'm especially surprised when I come across people who say they ``live in their Gmail'' and actually do live in the web-app.
- JetSpiegel 12y ago
  The worse thing is totally different interfaces between different mail providers. It makes impossible to have multiple email addresses and manage them in a sane manner. Do you have any primers to use mutt? I really wanted a terminal-based alternative to Thunderbird in case I need to ssh from somewhere, or if I'm in a hurry, but the man page alone scares me.
  - zAy0LfpBZLC8mAC 12y ago
    Just start it? In the standard config, it has a help line that tells you about all the most common key bindings, I'd think it really isn't difficult to get started and look things up in the manual as needed. If you are not on a fully configured unix system with an MTA and local mail spool, the only thing you'll have to set up to get started should be the mail server config.
    - JetSpiegel 12y ago
      Yeah, I need to find the time to just roll with it.

partomniscient 12y ago

The problem with RFC2822 (as with all specifications) is that it failed to correctly predict this future (and ideally all other possible futures).

zAy0LfpBZLC8mAC 12y ago
The good thing about RFC822 (and by extension RFC2822) is that it is extremely flexible instead of trying to predict the future and in the process creating an unimplementable monster of mispredictions (cf. OSI networking stack). Even though the stack of email RFCs contains quite some cruft due to historic accidents, it's actually not as bad as you might think when looking at all the terrible mail software out there that seems to be written by people who don't even bother to read the RFCs (which seems to include google, after all).
- partomniscient 12y ago
  I was being somewhat facetious, but you're correct. It's a balancing act of so many factors, many of which are beyond the originators control or realisation. Quite a while ago I considered trying to write an IMAP library for a language I used - after some brief research I concluded: that way lies madness.

bobbyi_settv 12y ago

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

Chinasol 12y ago

It's great to see the old 80-column punched card standard fossilised in these modern environments...

XorNot 12y ago
80 columns gives you 3 files side-by-side on a 1920 monitor.
- skj 12y ago
  Surely that depends on more than just the number of columns and the number of pixels.
wpietri 12y ago
And my understanding is that we got punched cards of that size because they fit into the boxes and drawers for large-format US banknotes: http://en.wikipedia.org/wiki/Large-sized_note http://en.wikipedia.org/wiki/Large-sized_note Which in turn apparently goes back to taking a common paper size and cutting it into reasonably-sized pieces: http://ask.metafilter.com/262846/What-is-the-origin-of-the-dimensions-of-large-sized-US-dollar-bills http://ask.metafilter.com/262846/What-is-the-origin-of-the-d... So apparently one person lost to history said, "How big should it be? I don't know. Maybe about this big?" Centuries later, somebody at IBM said, "It looks like we could fit 80 columns on that. Good enough?"
- kps 12y ago
  Hollerith cards originally had 45 columns.
kps 12y ago
Line length around 80 columns come from letter paper in a typewriter (via teleprinters) which in turn comes from book printing, where around 60–65 printed characters (plus blanks) were established as most readable centuries ago.

qwerta 12y ago

Why you just do not use different email client?

adamlafave 12y ago

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. I wrote about this here: http://adamlafave.com/email-parsing-dont-parse-text-plain/ http://adamlafave.com/email-parsing-dont-parse-text-plain/

zem 12y ago

i finally gave up and switched to sending html mail precisely because of this issue :(