26 Responses to “Talking Mail.app: drunkenbatman”

1. Chris Mear says:
   February 16th, 2006 at 5:41 am

   After x years of email, I associated quoted text as having a ?¢‚ǨÀú>?¢‚Ǩ‚Ñ¢ before it, and quoted quoted text as having ?¢‚ǨÀú>>?¢‚Ǩ‚Ñ¢, etc. In Mail.app, I get these damn lines. I don?¢‚Ǩ‚Ñ¢t necessarily have a problem with the lines, as I know lots of others like them ?¢‚Ǩ‚Äù but just deciding lines are what I should be using is arrogant.

   No, it’s not arrogance. It’s called ‘format=flowed’, and there’s a very good reason for it:

   http://www.joeclark.org/ffaq.html

2. Everyone Hates Apple Mail at soypunk says:
   February 16th, 2006 at 4:19 pm

   [...] Drukenbatman has some harsh words concerning Apple Mail in a recent interview. Here’s a choice quote when asked what part of Apple Mail he hated the most: [...]

3. Peter da Silva says:
   March 3rd, 2006 at 2:56 am

   Those damned lines in Mail.app are why I’m using elm.

   Because I can’t bloody well edit the quoted text down to the relevant bits without, at some point, deleting one too many characters and having part of the quote lose its “quotedness”. And can I get that “quotedness” back again? Not bloody likely! There’s no combination of “>” and indenting and unindenting and Plain Text and Rich Text (or even Poor-but-proud Text) that will let me compose a response the way I’m accustomed to.

   There’s no bloody reason it can’t let me edit the message as it’s actually going to go out, as it’s going to be seen by the people I correspond with using traditional mailers. It can set the “format=flowed” header so that it and other smart-arse mailers can show their blue lines and tidy up the wrapping in the message display window without giving me something that’s almost-but-not-quite-completely-unlike-plain-text and claiming it’s plain text.

   If that arrogance is the arrogance of the people who came up with format=flowed instead of Apple’s, that’s beside the point. It’s still arrogant and frustrating and just plain bloody stupid.

4. Chris Mear says:
   March 3rd, 2006 at 4:33 am

   Personally, I’ve never had any trouble editing quoted text in Mail. Can you give a specific example of when it screws up? I’m intrigued.

5. Peter da Silva says:
   March 3rd, 2006 at 6:13 am

   Select the first character of the quoted text. Hit backspace a couple of times until you’re on the attribution line. Hit return. Notice that the first line of text is now black.

   Try inserting any combination of tabs, >, space, and getting it to realise that line is part of the quote.

6. Chris Mear says:
   March 3rd, 2006 at 11:02 am

   You’re right, you can’t re-quote that text by entering characters. But instead of trying to trick Mail into doing what you want, just tell it: select Format > Quote Level > Increase (or hit Cmd’). You should find that it re-quotes the text.

   I remember finding this whole thing a bit weird at first, but once you learn to trust Mail to do the right thing behind the scenes, the quoting really does work smoothly. And now that it’s part of my muscle memory, I know I prefer to entering ‘>’s by hand.

7. Peter da Silva says:
   March 3rd, 2006 at 3:11 pm

   That’s the daftest thing I ever heard of. Using the formatting menu to edit plain text.

   Not going to get any muscle memory, since I can’t use mail.app over a telnet connection so I can’t use it for all my mail. Guess I’m sticking with elm… which might be old and crufty but at least it doesn’t call rich text “plain text”.

8. Chris Mear says:
   March 3rd, 2006 at 6:12 pm

   Why’s it so daft? Email isn’t just plain text — it’s a particular data format that specifies certain rules. In the modern world of email on screens that can manage more than 80-character lines, one of these rules is format=flowed quoting. I, for one, am happy to have a helper that applies these tedious rules for me automatically, giving me an enhanced experience.

   I’ll admit that initially it does feel strange to not have ‘full control’ over your text. But I’ve come to view it as a similar thing to, for instance, the way Mail automatically encodes file attachments into plain text, and displays them as an icon.

   I’m not bothered that Mail doesn’t allow me to edit the raw MIME data, because I’d gain absolutely no benefit from being able to do that. In fact, I’d probably break something. Instead, I manipulate attachments using the GUI, and trust that Mail is doing the right thing behind the scenes.

   It’s the same thing with quoting.

9. Peter da Silva says:
   March 3rd, 2006 at 9:25 pm

   This has nothing to do with MIME encoding or the “raw MIME data”. Format=flowed doesn’t change the encoding of the text, it’s just a hint to the receiving program as to how to display it. It’s optional, and it should be optional in the editor as well.

   That is, if “mail isn?¢‚Ǩ‚Ñ¢t just plain text” then Mail.app shouldn’t call it “plain text”. It should call it “unformatted” or “simple” or something that represents what it’s actually doing, and if you specify “plain text” it shouldn’t allow attachments without upgrading to “unformatted”… just as it ddoesn’t allow you to edit markup without upgrading to “rich text”.

   This really matters, because the Internet is full of mailing list software, mail gateways, and other automated software that’s designed to work with “plain text” really does expect mail with a body that’s not encoded, not encapsulated, just pure RFC822.

   If it’s common for mail software to send encoded mail and claim it’s “plain text”, no wonder I’ve had so much trouble over the years with users trying to convince their mail software to send unmodified raw plain text mail to things like pager gateways. No wonder I’ve had so much trouble when programs like Lotus Notes trashed “plain text” mail containing snippets of source code, or choke on what the originator swore was “plain text”.

   This is Apple’s arrogance, Qualcomm’s arrogance: plain text mail is used for much more than sending memos.

10. Chris Mear says:
    March 3rd, 2006 at 10:01 pm

    Yes, I know that format=flowed isn’t related at a technical level to MIME encoding. I was just making a comparison to demonstrate the similarity of the mental model I apply to any situation where an app ‘just looks after’ something for me.

    Anyway. I don’t understand why you think there’ll be problems with mail gateways and what-not. Format=flowed is just a convention on top of the basic RFC822 standard. Using format=flowed doesn’t change the fact that

    > the underlying data
    > is still normal plain text
    > sent like this, just like
    > it’s always been.

    And (unless your mail client’s implementation of format=flowed is completely borked) you can still stick source code, patch files, whatever the heck you like, right in the body of the email. The worst that will happen is you might gain an extra space at the end of a line if you’re reading it in a client that doesn’t understand format=flowed, and the line was longer than 80 characters. But anyway, in that situation, your client would probably end up screwing it up even if you were using plain vanilla text:

    >>> Ever seen something like
    > this before?
    >>> It’s a pain in the butt.

    It’s a fair point that Apple could have made format=flowed a user preference in Mail. But in general, Apple leans towards fewer confusing technical options. Especially in a situation like this, where the decision to have format=flowed switched on really doesn’t make any difference to the business end of things. As you say, it’s a user interface convenience — why not just leave it in?

    If you want to talk about arrogance, let’s talk about TNEF.

11. Peter da Silva says:
    March 3rd, 2006 at 11:17 pm

    “The worst that will happen is you might gain an extra space at the end of a line if you?¢‚Ǩ‚Ñ¢re reading it in a client that doesn?¢‚Ǩ‚Ñ¢t understand format=flowed”

    The worst that will happen is that lines are broken at random places, and leading spaces are lost, and multiple lines are concatenated together. A client that sends mail as “plain text” does none of those things. The “>>>…>…>>>” problem is already the result of a client trying to format plain text.

    Also, as implemented, it’s a user-interface inconvenience:

    If I’m editing with “format=flowed”, and I’m at the beginning of a paragraph, and I enter the string “> “, what should happen? Here’s the options

    * Mail displays it as “> ” but it goes out as an extra level of quoting.
    * Mail displays it as “> ” and tries to ‘hide’ it, so it may or may not appear as an extra level of quoting depending on the recipient.
    * Mail inserts an extra level of quoting.

    It appears that Mail does #2. What’s wrong with #3?

12. Chris Mear says:
    March 3rd, 2006 at 11:48 pm

    A client that sends mail as ?¢‚Ǩ?ìplain text?¢‚Ǩ¬ù does none of those things

    Not always true. There are plenty of plain text email clients that will automatically truncate lines to 80 characters, and you’ll get exactly the same problems.

    What?¢‚Ǩ‚Ñ¢s wrong with #3?

    You forgot option #4, which is “I just want to type a right angled bracket as part of the content of this email.” I really don’t understand why you’re so desperate to have the ability to wrangle with all this quoting manually. What do you gain? What do you lose from having the program take care of it for you?

13. Peter da Silva says:
    March 4th, 2006 at 12:31 pm

    There are plenty of plain text email clients that will automatically truncate lines to 80 characters,

    Name one currently in use. Twenty years ago, when it was ARPANET and DECNET and BITNET and addresses looked like uunet!decwrl%bitrelay!BITNET!IEH666, yes. Now, though?

    You forgot option #4, which is ?¢‚Ǩ?ìI just want to type a right angled bracket as part of the content of this email.?¢‚Ǩ¬ù

    That’s option 2. Really.

14. Chris Mear says:
    March 4th, 2006 at 7:37 pm

    Name one currently in use.

    Gmail. Outlook. Thunderbird (with format=flowed turned off). Squirrelmail. Any client that follows the recommendations of RFC 2822.

    That?¢‚Ǩ‚Ñ¢s option 2.

    You’re right, sorry. My slip.

    But what’s so wrong with that behaviour? It makes perfect sense in the context of a client that is always managing the quoting on your behalf. What’s wrong with 3 is that, in that context, that behaviour would result in an odd exception to the usual rule.

    And I totally agree, 3 is the correct behaviour if you’re using a client that doesn’t support format=flowed, and actually shows you all of the ‘>’ quote symbols.

    In other words, the correct, logical behaviour for what happens when you enter ‘>’ follows directly from whether the app actually shows you the quote symbols as part of the message, or whether the app shows attribution lines and does the quoting for you behind the scenes (in order to help with format=flowed). What we really disagree on is that overall concept, not the specifics of the behaviour.

15. Peter da Silva says:
    March 4th, 2006 at 10:39 pm

    I haven’t used all of those programs, but none of the ones i’ve used truncate lines at all, let alone specifically at 80 characters. THey either hard-wrap at page width, or scroll sideways.

    But what?¢‚Ǩ‚Ñ¢s so wrong with that behaviour?

    Because you don’t know whether the recipient is going to see that text as quoted or not.

    If you don’t care if you’re actually seeing what’s going out, why bother with plain text at all?

16. Pierre says:
    March 7th, 2006 at 1:42 am

    As soon as an e-mail client hard-wraps quoted text, we have the problems described by Chris. His example:

    >>> Ever seen something like
    > this before?
    >>> It?¢‚Ǩ‚Ñ¢s a pain in the butt.

    is caused by an e-mail client using hard-wrap. Whether it’s at 80 chars or at page width, it doesn’t matter. It’s hard-wrap, and it screws up everything. And it’s precisely why Qualcomm came up with f=f, and precisely why Apple adopted it in Mail.

    The very concept of using hard-wrap and “>” at the beginning of each line is completely twisted, because it effectively inserts foreign characters INSIDE the text.

    I fail to see how having a “pure” plain text client addresses this problem. It’s a horrible limitation of plain-text e-mail and I for one am glad that Qualcomm and Apple came up with an elegant way around it that still preserves the plain-text nature of e-mail.

    Now, Apple’s implementation of f=f is not perfect, far from it. But it’s way better than having to deal with “>” chars.

17. Peter da Silva says:
    March 7th, 2006 at 10:46 am

    1. format=flowed still inserts those “>” characters into the text.
    2. “hard wrap at page width” is purely a function of the display, it doesn’t produce the problem you’re talking about. *soft* wrap, on word boundaries, and the use of an editor that doesn’t preserve line boundaries when displaying wrapped text does.
    3. Whether you use vertical lines or “>” characters or boxes (as typical threaded forums do) to indicate quoting is orthogonal to whether you’re using format=flowed or not.
    4. format=flowed does not preserve the “plain text” nature of e-mail.

18. Pierre says:
    March 7th, 2006 at 1:38 pm

    1. It does, but AFAIR only at the time the message is sent, not while you are editing it.

    2. Hard wrap is bad, period. Your display has a certain width. Mine has another. Text hard-wrapped for yours will look ugly on mine. And these return chars will be inserted irreparably.

    3. We are not discussing the aesthetics of it here. We are discussing the functionality. The good thing about f=f is that it makes quoting quoted (quoted (quoted)) text less of a pain. There’s no question that using a single “Increase/Decrease Quote Level” command for an entire paragraph is more convenient than having to manually insert a “> ” at the beginning of each line (and manually correct all the broken stuff caused by the hard-wrap).

    4. Last time I checked, a f=f formatted e-mail is still just a bunch of plain text. f=f only affects the way plain text messages are read/composed. Not the way that they are ultimately transmitted (except for the header information, of course).

19. Chris Mear says:
    March 7th, 2006 at 5:30 pm

    Peter, you’re using ‘hard wrapping’ and ’soft wrapping’ in the opposite sense to how most people understand those terms. Hard wrapping is when the wrapping (either to screen width or pixel width) is subsequently written to the data stream using newline characters; soft wrapping is when no change is made to the actual data.

    I haven?¢‚Ǩ‚Ñ¢t used all of those programs, but none of the ones i?¢‚Ǩ‚Ñ¢ve used truncate lines at all, let alone specifically at 80 characters.

    That’s nice for you, but the fact is that it’s a common, standard thing for email clients to hard-wrap plain text emails at 78 characters when they format the email for sending. So you simply can’t rely on your 348-line plain text emails coming back to you unwrapped. And yeah, that sucks. But it’s just how it is.

    Because you don?¢‚Ǩ‚Ñ¢t know whether the recipient is going to see that text as quoted or not.

    Actually, you do. It’s a very, very simple rule. If you type a ‘>’ in Mail, it will go out as part of the message, not at the start of a line as quote character.

    By contrast, suppose you’re using a plain text emailer which hard-wraps at 78 characters. You type a line starting with 77 characters, then a space, then a ‘>’, then finishing with more text. That’ll get sent as two lines, the second of which begins with a ‘>’ in the first column — looking, rather confusingly, just like a quote mark.

    If you’re writing emails that actually contain ‘>’s in the content, format=flowed is vastyl superior.

    format=flowed does not preserve the ?¢‚Ǩ?ìplain text?¢‚Ǩ¬ù nature of e-mail.

    Thing is, you’re talking about a kind of ‘ideal plain text’ where no hard wrapping occurs, and lines are preserved at whatever length you write them. But that doesn’t exist in the real world, unless you go and audit the email clients of everyone you correspond with.

    Given the 78-character hard-wrapping that can occur with ‘real-word plain text’ email, format=flowed actually preserves your content far better than plain text.

20. Peter da Silva says:
    March 7th, 2006 at 11:54 pm

    Hard wrapping is wrapping at a hard limit, as opposed to looking for a word boundary and wrapping there. But, whatever, I’ll use your terminology, so let’s go back several messages and ignore the confusion that caused.

    So, read the paragraph where I said “hard wrap” as “I haven?¢‚Ǩ‚Ñ¢t used all of those programs, but none of the ones i?¢‚Ǩ‚Ñ¢ve used truncate lines at all, let alone specifically at 80 characters. They either visually wrap at page width, or scroll sideways, but do not change the content of the message”

    Hard wrap (as you define it) is bad, but hard wrap is not and never has been something that traditional plain-text mail programs ever did. It’s something that mail programs that try and make plain-text behave like rich-text do.

    The right thing to do about that is to stop trying to reflow text and inserting newlines that weren’t in there in the first place. If the result is mail with long lines, then send mail with long lines. Those long lines may be necessary!

    “There?¢‚Ǩ‚Ñ¢s no question that using a single ?¢‚Ǩ?ìIncrease/Decrease Quote Level?¢‚Ǩ¬ù command for an entire paragraph is more convenient than having to manually insert a ?¢‚Ǩ?ì> ?¢‚Ǩ¬ù at the beginning of each line (and manually correct all the broken stuff caused by the hard-wrap).”

    But it’s less convenient than simply not breaking stuff in the first place.

    “Last time I checked, a f=f formatted e-mail is still just a bunch of plain text.”

    If it is, then so is HTML e-mail. It’s converted from plain-text to rich-text when the display program interprets the markup embedded in the text. Just like “f=f”.

    “the fact is that it?¢‚Ǩ‚Ñ¢s a common, standard thing for email clients to hard-wrap plain text emails at 78 characters when they format the email for sending.”

    That’s a *problem* and it’s companies like Qualcomm that created that problem when they made Eudora hard-wrap text. The solution is not to further corrupt the mail, it’s to use rich-text mail when you want to embed markup in the message, and leave plain-text alone.

    “Thing is, you?¢‚Ǩ‚Ñ¢re talking about a kind of ?¢‚ǨÀúideal plain text?¢‚Ǩ‚Ñ¢ where no hard wrapping occurs,”

    That’s right. That’s what plain-text mail software does. That’s what every piece of mail software I ever used before Apple Mail does, and that’s what I expect when people tell me they’re sending plain text. Obviously, the rot has run deeper than I knew.

    “Actually, you do. It?¢‚Ǩ‚Ñ¢s a very, very simple rule. If you type a ?¢‚ǨÀú>?¢‚Ǩ‚Ñ¢ in Mail, it will go out as part of the message, not at the start of a line as quote character.”

    If I’m at the beginning of a paragraph (which is where Apple Mail trashes the quote level in normal editing). and I type “> This is not a quote”, then that “>” is going to go out at the beginning of a line.

    For that matter, why is it that if I erase back from the beginning of a quoted paragraph does it let me “delete the >” using normal “insert and delete character” operations (which you say it shouldn’t do), but when I hit command-Z to undo it _it doesn’t put the quote back_?

21. Pierre says:
    March 8th, 2006 at 1:03 am

    Peter, the problem is that the vast majority of e-mail clients DO use hard-wrapping (i.e. break the lines of a paragraph by inserting carriage returns). Nothing you and I might say or do can change this fact.

    In light of this, the f=f behaviour is probably the best possible solution. Yes, ideally, e-mail clients should not insert carriage returns. But they do. (You need to remember that this behaviour was introduced because far too many Internet tools were too dumb to do soft-wrapping, thereby forcing users to scroll HORIZONTALLY to read entire paragraphs on a single line. It was pretty ridiculous.)

    If you are lucky enough to have only ever used e-mail clients that don’t do any hard-wrapping, then good for you. But the experience of most people in the real world is that hard-wrapping is everywhere.

    When I say that f=f e-mail is still plain text, I refer to what the actual RAW SOURCE Of the message is. The only difference between a plain text message without f=f and a plain text message with f=f is the header information about f=f. The body of the message as sent or received is untouched. It still uses “>” characters. There’s no HTML code or RTF tags or anything in the body of the message. It’s plain text.

22. Peter da Silva says:
    March 8th, 2006 at 1:18 am

    “In light of this, the f=f behaviour is probably the best possible solution.”

    Err, if the mail program is going to rewrap, and it knows about “>” quoting, it’s perfectly capable of rewrapping and keeping the “>” quoting intact without hiding it.

    “I refer to what the actual RAW SOURCE Of the message is. The only difference between a plain text message without f=f and a plain text message with f=f is the header information about f=f.”

    I’m also referring to the raw message.

    If someone cuts some error messages out of a window and sends them to me, and what I receive has all the lines in the message run together, leading spaces trimmed, and “smart quotes” replacing the original quotes, that’s not “plain text”.

    Whether it can be converted back to the original if I happen to have a “format=flowed-aware” mail reader is pretty much irrelevant.

    “The body of the message as sent or received is untouched. It still uses ?¢‚Ǩ?ì>?¢‚Ǩ¬ù characters.”

    But it doesn’t put them where the original message had them. And it inserts extra characters to indicate where flowing “should” happen and (presumably) to quote “real” leading “>” so they’re not confused with a level of quoting. Just because the markup appears to be whitespace doesn’t mean it’s not there. There’s mail clients that send rich text with all the markup encoded in sequences of taps and spaces at the end of the line, exactly as “f=f” does… it’s still rich text.

23. Pierre says:
    March 8th, 2006 at 3:25 am

    Rewrapping and keeping the “>” quoting intact is exactly what Mail does. The only difference is that it shows the quoting as lines rather than as “>” characters. But that’s purely a matter of aesthetics.

    If you want a program to handle quoting levels automatically, you have to give up some degree of control over individual “>” characters. Mail’s lines (and colours) are Apple’s way of illustrating the degree of control that you lose (and the advantages that you gain). If they had left individual “>” chars visible, then users might have been tempted to try and type additional “>” chars manually, which would have screwed up the whole automatic rewrapping and quoting.

    By definition, plain text is text without styles/formatting. Whether there are smart quotes or straight quotes or spaces trimmed or line breaks removed or added doesn’t change anything to the fact that it is still plain text. There are several possible character sets, some of which include a variety of additional characters (ISO-Latin and Unicode both include curly quotes, for example). But that’s a character encoding issue. It has nothing to do with rich text vs. plain text. Plain text e-mail messages with f=f are still plain text. The problems you describe have more to do with what Mail does with text copied and pasted from another application. Depending on your preferences, Mail might try to convert/delete certain characters. It’s not particularly clever at that, I’ll grant you that, but that doesn’t have anything to do with the plain text nature of the end product.

    As for rich formatting code being hidden in white space, I’ll leave that to the conspiracy theorists :).

24. Peter da Silva says:
    March 8th, 2006 at 11:03 am

    Quoting is formatting. The whole premise behind f=f is that quoting is formatting and not content.

    Line breaks are formatting.

    And… If you want a program to handle quoting levels automatically,?

    What if I don’t want that?

    The problems you describe have more to do with what Mail does with text copied and pasted from another application.

    It doesn’t matter if I type the text in by hand, the result is the same.

    fprintf(stderr, “%-40s %s %02d:%02d:%02d %04d/%02d/%02d %s”, current->tag, “This is the label and if there’s a newline in this string the code won’t compile”, current->date[0], current->date[1], current->date[2], current->date[3], current->date[4], current->date[5], current->status);

    I didn’t type any newlines in there. That’s a single line.

    Also, no text was copied and pasted when Mail decided to lose the formatting on the first line of a paragraph when I backspaced too far. And… it must have been hard-wrapping that line because ONLY that line, not the whole paragraph, got “unquoted”.

25. Jacob says:
    March 19th, 2006 at 4:38 am

    Peter, go ahead and use Mutt or whatever, just don’t send me any email

    
> > > that looks like it
> just
> > got
> > > popped or maybe
> > pooped
> > > out of a toaster
> or
> > > something


26. Peter da Silva says:
    March 21st, 2006 at 2:16 am

    So long as you don’t send me email in MS-Comic-Sans, or mail that looks like

    <quote>

    &gt; &gt; &gt; Whoops…
    &gt; &gt; &gt; Too late.
    &gt; &gt; &gt; You already did.
    &gt; &gt; &gt; But it wasn’t your fault.

    </quote>

Leave a Reply