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


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


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

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

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.

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.

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_?

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.

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