1. 5
    Back to 40 columns ask email

You might know about a not so remote past, in which computer folks struggled for having 80 columns. You might also know how, even nowadays, some programmers tend to restrict code lines length as a way to increase readability.

I personally feel slightly annoyed when a document (e.g. an email) that carefully avoids exceeding the sacred 80 columns limit, renders horribly anyway in your hand-held device, forcing you to rotate it landscape.

I have a 76 column cap in my ~/.vimrc, but I start to think I should make it 40~ish for email composition (invoked from mutt) so that it doesn’t render horribly in mobile mail clients.

Do you have any special habit to tackle this problem?

  1.  

  2. 23

    Have you considered not putting hard end-of-lines at all? This way your mail should be readable by all readers: mobile, tablet, horizontal/vertical, terminal, etc. It would be only a matter of setting your terminal size to 80 chars wide, if your mail reader doesn’t support soft wrapping.

    Sentences in the mail are not code. It’s natural to wrap them. We do it all the time in books, articles, lobste.rs comments, etc. It allows people to use different fonts, different sizes (some people see worse than others, have to use bigger fonts), different devices, etc.

    Is it natural to

    write a comment

    like this? What

    is the point of

    the newline cha-

    racter here?

    That is, of course, with respect for rules imposed by mailing lists. E.g. if OpenBSD mailing list require 72 chars, then everyone should respect this setting.

    1. 5

      Have you considered not putting hard end-of-lines at all?

      I think this is the way to go. Every client will be able to render the text the way it looks best. How about limiting lobste.rs to 72 characters? Where’s the difference? That was a rhetorical question :-)

      On the other hand: This is a classic debate that will most likely never have an end. It’s preference. And thus I have to live with badly readable mail, when reading on mobile.

      But I tend to prefer tabs instead of spaces, so… what sane person would take me serious?

      1. 1

        Sentences in the mail are not code. It’s natural to wrap them.

        Sentences in e-mail are, however, often quoted. It’s much easier to take one sentence and quote it if it’s on a separate line. Newlines after punctuation are a feature, not a bug when it comes to e-mail.

        That is, of course, with respect for rules imposed by mailing lists

        Since people composing their e-mail in e-mail clients would have to go and hunt down the setting to control the line length limit to match the rules imposed by mailing lists, there’s kind of a natural race to the bottom for settings that comply with the most mailing lists.

        1. 3

          I’m pretty sure you can select text with a mouse and copy it…

          1. 2

            Sentences in the mail are not code. It’s natural to wrap them.

            Sentences in e-mail are, however, often quoted. It’s much easier to take one sentence and quote it if it’s on a separate line. Newlines after punctuation are a feature, not a bug when it comes to e-mail.

            Do you suggest that long lines without hard end-of-lines and quoting are incompatible, or hard to perform?

            But even if, then still, personally I believe that it’s more important that lots of people will be able to conveniently read what I write, than my personal convenience of editing such an e-mail.

        2. 9

          RFC 3676 is very widely implemented and solves this in the way you want. You’re either looking for that or looking to reinvent it.

          I’m curious how you might get vim to insert/preserve those spaces, though.

          1. 3

            vimrc: autocmd FileType mail setlocal formatoptions+=aw
            muttrc: set text_flowed=yes

          2. 2

            I have a question for the people who advocate hard wrapping at 72 chars: how do you send code or patches?

            I once wanted to send a patch to a mailing list-based project, so I contributed Thunderbird to wrap at 72 chars, wrote my blurb about what the patch does and why I think it’s a good idea, went to paste my git format-patch formatted patch… and Thunderbird broke it, because you can’t just hard wrap a patch file arbitrarily and expect it to still work.

            What would be the proper way to solve this? Do you guys use email clients which know to recognize a patch file and disable wrapping for that? Or do you make sure every line in the project is less than 70 chars and every file path is less than 30 chars? Or do you manually add the newlines? Or is there some magical solution I don’t know about?

            1. 3

              The easy and unhelpful answer is that you don’t send patches with Thunderbird, you send them with git send-email directly to your SMTP server.

              Unfortunately, that doesn’t help if your SMTP server is Gmail, since apparently it hard-wraps all plain-text messages that pass through their system, not just ones that come from the web-based UI.

              1. 1

                WUT?

                It is a long time since I stopped using Google products (minus android on my derp-phone), so I can’t have a defined opinion on the topic. It is however the second lobsters thread in a short time where I read of really bad decisions from Google.

                Are they cutting on quality or messing with people on purpose? O_o

                1. 1

                  The other day I was talking with somebody trying to send a patch through Gmail, and they couldn’t get it to stop wrapping. They dug into it and apparently Gmail wrapping plain-text emails is Just Something That Happens, it’s been that way since the early days and nobody on the Gmail team cares enough to change it.

              2. 1

                There’s a good tutorial for sending patches to mailing lists here: https://git-send-email.io/

                It’s pretty nice once you set things up.

              3. 1

                Not entirely related, but i have started adopting semantic linefeeds when writing. It’s surprisingly nice when you get used to it.

                https://rhodesmill.org/brandon/2012/one-sentence-per-line/

                1. 1

                  I love semantic linefeeds for writing that will be automatically typeset later, like Markdown. It’s a bit more awkward for content that other humans will read directly, since it tends to read like free verse and (as you mention) it takes a bit of getting used to.

                2. 1

                  Yes, let email clients (and their operators) wrap where they please, and stop trying to tell everybody else how wide their text reading should be.

                  1. 1

                    Given that OpenBSD mailing lists require 72 characters per line, that’s what I send, but not necessarily expect to receive. Considering mobile clients seem to aggressively render in non-monospace fonts from what I’ve heard, this should be reasonable on mobile as well, so I myself see no reason to change it.

                    1. 1

                      What’s “aggressive” about rendering non-code text nicely?

                      And no, as someone who sometimes reads mail on a phone, 72-char wrapped non-monospace text on a phone doesn’t look reasonable. Phones usually don’t have the horizontal space for 72 characters even when using a proportional font.

                      EDIT: To illustrate, here’s how an email from launchpad looks like in my phone’s email client: https://cloud.mort.coffee/s/LN2C34S6wTntJQ2/preview - the 72 characters end up being a bit less than 1.5 actual lines, so you end up with a jarring reading experience with unnatural pauses every other line because some piece of software decided there had to be a physical newline there.

                    2. 1

                      honestly, hadn’t thought about it, really good question. I’d probably use bsd mail in a terminal on my phone.