Closed Bug 86607 Opened 24 years ago Closed 5 years ago

UI option for disabling format=flowed

Categories

(MailNews Core :: Composition, enhancement)

Product:
MailNews Core
Component:
Composition
Platform:
x86
All
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: holgermetzger, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: mailnews.send_plaintext_flowed = false)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 BuildID: any build Please add an UI option for disabling format=flowed. The possibility for disabling f=f is already available via prefs.js/mailnews.js anyway. In my opinion format=flowed impairs legibility on high resolution screens (e.g. 1600x1200 higher/less): one seemingly never-ending line is extremely tiring for the eyes, especially when reading long emails/news. A break after a certain line length (72 - 75 is common) really helps a lot. I know f=f is a nifty feature for many, but I'm sure there are equally many people out there who prefer reading mails "the old way". Reproducible: Always Steps to Reproduce: reading mails/news.
See bug 71110. I think it would fix the problems you're having...
That's not whatI have in mind. I rather have an option for completely disabling it, via the preferences UI. OK, it's quite easy to disable by editing prefs.js/mailnews.js, but for the enduser who's confused about the not-breaking of his lines Mozilla should provide an UI option.
change qa contact ->ninoschka
QA Contact: sheelar → nbaca
reassign to varada
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: ui
Summary: UI option for disabling format=flowed → [RFE] UI option for disabling format=flowed
I vote for not fixing this. format=flowed is very useful and doesn't hurt. I have heard 3 reasons for disabling it (for viewer): - Too long lines (as in initial description). This is already covered by bug 71110. - The blue/grey bar. "We want >!". I can't understand what problem some people have with bars, but there seems to be a few people that do. That's covered by bug 88986. Note that this is different from disabling format=flowed altogether. If you disable format=flowed, you *don't* see what the sender intended. For these reasons, I suggest WONTFIX. I assume, Holger asks for disabling f=f in the *viewer*, not during send. I cannot see a valid reason for the latter. > for the enduser who's confused about the not-breaking > of his lines Mozilla should provide an UI option. huh? How are end-users confused about "non-breaking lines"? It's the same with HTML and MS Word documents, and we don't have an option there either. The fact that format=flowed does have linebreaks at ~72 chars is only for legacy reasons, similar to the linebreaks you use in HTML-source. These breaks have no logical meaning. We don't have an option to always show the HTML-source in the main browser window either.
As long as the prefs option for disabling f=f stays intact, I don't mind a WONTFIX. > I assume, Holger asks for disabling f=f in the *viewer*, not during send. I > cannot see a valid reason for the latter. No, in both. > If you disable format=flowed, you *don't* see what the sender intended. I see as the sender composed the message, how he/she saw it. f=f kicks into action when the message has been sent. The sender doesn't see his/her message in f=f. So what the sender intended me to see... hmm.. I don't know... > huh? How are end-users confused about "non-breaking lines"? Because they are, they truly are. That's a favorite question. "Why does my Netscape 6.x not break lines? When I compose a message, Netscape 6.x breaks my lines just fine, but seems to forget the line-break when the message has been sent. What gives?" IMHO, f=f is completely unnecessary. Mozilla has a truly excellent mail/news editor that can do without f=f just fine. Just because it's something "new'n nifty" doesn't mean it's better. Strictly IMHO.
> As long as the prefs option for disabling f=f stays intact, I don't mind a > WONTFIX. Yup, I was speaking about the UI pref only. I don't mind backend-prefs. > > I assume, Holger asks for disabling f=f in the *viewer*, not during send. I > > cannot see a valid reason for the latter. > No, in both. Why? > If you disable format=flowed, you *don't* see what the sender intended. > I see as the sender composed the message, how he/she saw it. No, you don't > The sender doesn't see his/her message in f=f. He does. In the HTML composer, the lines flow at window width - just as you see them in the viewer when you recieve the mail sent as f=f. In the plaintext composer, the lines flow as well, just that they are wrapped at 72 chars or so. Bug 71110 would do that in the viewer. If the sender wants a linebreak at a certain point for all recipients, he has to hit enter, in which case a hard break will be inserted in the f=f mail, which you will see in the viewer as well. > "Why does my Netscape 6.x not break lines? When I compose a message, > Netscape 6.x breaks my lines just fine [That's speaking about the plaintext composer only] Well, you could argue that the plaintext composer should not wrap at 72 chars, then. Note that when using the HTML composer, lines wrap at window width. Disabling f=f here would create the exact opposite problem you describe (people compose floating lines, but recieve fixed width lines). > f=f is completely unnecessary. That's wrong. With normal plaintext, you can't even say for sure, what was a quote. See RFC2646 <ftp://ftp.isi.edu/in-notes/rfc2646.txt>, Section 3 for more rationales.
> Yup, I was speaking about the UI pref only. I don't mind backend-prefs. That's good. > Why? Because viewing a mail with a fix line-break is better for my eyes. Reading f=f on a large screen is unbearable. Sending because I sometimes use boxquotes that get destroyed with f=f. > In the HTML composer... I'm not even thinking about using the HTML composer, so that's not an issue for me. > If the sender wants a linebreak at a certain point for all recipients, he has > to hit enter, in which case a hard break will be inserted That's exactly what I don't want to do. I want my email program to break lines at a certain point which can also be seen on screen, not in the source only. Basically, I want Mozilla behave Mozilla/4 style. > That's wrong. With normal plaintext, you can't even say for sure, what was a > quote. Hmmm, I'm not sure I understand. So the text with ">" was something else? I lived in a dreamworld for the last couple of years? :) In any case: I want to choose how Mozilla behaves. And I'm sure there are other people out there who feel the same. If an UI option is a WONTFIX, that's fine by me as long as the backend option remains intact. I read RFC-2646, but I still don't see any valid reason for f=f. Maybe I should rr-read it.
> Hmmm, I'm not sure I understand. So the text with ">" was something else? I > lived in a dreamworld for the last couple of years? :) Lines beginning with '>' might be quotes and often is, but not always. f=f contains a method to seperate lines beginning with '>' from real quotes. Also, if the issue is that the lines are too wide to read easily, please argue for that bug to be fixed instead of throwing away the child with the water. By the way, why do you have to control the line breaks in text in the mails you send? I don't see the point. For instance you make your mails less than perfect for people with narrow windows, like mobile users. Have you considered the possibility of taking advantage of f=f instead of complaining on the rough edges in Mozilla's implementation?
> Sending because I sometimes use boxquotes that get destroyed with f=f. > I want my email program to break lines at a certain point which can also be > seen on screen, not in the source only. Basically, I want Mozilla behave > Mozilla/4 style. Unless you can come up with a common case, where f=f messes things up and which cannot be fixed, you'll have a hard time to argue a UI option to disable f=f sending with me. Sending format is not *your* preference, but the reciepient's one. If the recipient doesn't like f=f, he can disable it and see the lines with the hard breaks in the source. But recipients which like flowed text (which, I assume, are most of them, assuming bug 71110 is fixed), can read your mails that way. > > In the HTML composer... > > I'm not even thinking about using the HTML composer, so that's not an issue > for me. But many other people do, and we need to consider them. > I read RFC-2646, but I still don't see any valid reason for f=f. Maybe I > should rr-read it. Check Section 3.2 (IIRC), "Embarrasing line wrap". What's said there is an understatement of the problems, as you can witness on n.p.mozilla.general (posts by Outlook Express and followups to these). Also, PDAs get very common recently.
> Check Section 3.2 (IIRC), "Embarrasing line wrap". What's said there is an > understatement of the problems, as you can witness on n.p.mozilla.general > (posts by Outlook Express and followups to these). Also, PDAs get very common > recently. Using f=f is not an absolution for horrible line wrapping. Other MUA's and newsreaders do line-wrapping just fine without f=f. f=f should not be the replacement for a poor editor. Mozilla's mail/news editor has always been excellent. In Mozilla 3/4 line wrapping occurs only in 2 situations (hard returns and re-editing of mails in the unsent messages folder), otherwise Mozilla 3/4 does an excellent job when it comes to word wrapping, without using f=f. Slrn, tin, gnus have no problem whatsoever with word-wrapping. The mail/news editor has to be excellent (and OE's just isn't). Even with f=f completely disabled: Mozilla/5 wraps lines absolutely perfect. I really don't see the need for f=f because of problematic word-wrapping a la OE style. But I can see that this discussion is rather useless... :) Just leave the backend option in and I'm happy.
reassign to varada...
Assignee: ducarroz → varada
QA Contact: nbaca → olgam
additional to #12 if answering to an f=f-posting, you get often with clicking on "send" wrong quote-signs. Instead of ">" you're getting " >", what won't be recognized. In the pülaintext-editor, you see it correctly, but when sending it, the blank will bee added. This happens tho f=f-users too, if they're quoting f=f-postings e.g. <3D5F8845.3020407@mollik.net> another problem caused by f=f is the wrapping of answers, like Holger described. (you're answer is only one line) for myself I mark my text, Strg-X and Strg-V. With that I get a correctly wrapped (72chars) answer. like the adding of a blank to the ">", sometimes a second line is added to you're answer. I think that "bug" is discribed somewhere else, but is caused bei f=f too. you're writing sth like that: =============== example ============= > Quote Quote > another quote my new text another line text ===================================== after sending and receiving it, it will be shown like that ============== example ============= > Quote Quote > another quote my new text another line text ===================================== workaround: put the caret at the end of the quoted text, hit "bckspce" two times, press enter, enter and write you're answer. if you do so, it won't be changed by mozilla before sending f=f gives a great help to this three "bugs"
Composing plain text messages is now very difficult. * There is now way to specify format=fixed vs. format=flowed * There is no easy way to visually distinguish whether there is a space at the end of plain text lines. You have to move the cursor to the end of each line and look for spaces. So even if you want to compose a format=flowed message (which is your only choice evidently), you still are subject to the "Embarrasing line wrap" problem. The user needs a way to: * select format=fixed or format=flowed for outgoing messages, * see which lines have hard vs soft breaks when composing format=flowed, * choose whether to view format=flowed without going to view/Msg source. I understand you don't see the need for this, and thus want to leave it as WONTFIX. Understand also that the current behavior is a show-stopper for some of us.
If I may say something, here is a brief summary of how I see that this issue could be addressed without creating hassles for both f=f supporters and opposers: * Dropping Mozilla's support for f=f should be out of question as its advantages (reformatting abilities, "smart" quoting, etc.) surpass any possible inconvenience. * It is true, however, that the legibility of a message may be impaired when it is displayed with overly long lines. * The option to control wrapping when composing messages is great. Long lines are as bad when composing a message as they are when reading one. * Given that, why not provide a way for users to specify their preferred wrapping point when reading messages as well? That might probably apply only for f=f messages, since reformatting is facilitated. Anyway, that could be done through an option on the "Message Display" section of the preferences dialog, similar to the one that exists for the "Composition" section. Alternatively, or in addition, there could be a graphical element, such as a slider that would control the right margin, as proposed by another poster. The bottom line is that f=f is definitely a good thing to have, but that does not mean that users should not have ways to make the display of those messages be comfortable to them. As a matter of fact, the very fact that f=f support is available should make this even easier to realize. Regards, Zunino
Ney, I agree, see comment 6, where I referenced bug 71110.
When sending messages, format=flowed should be off by default. Having it on means that the message may be altered without the sender knowing, when viewed on a client which interprets format=flowed messages by rewrapping the lines. Its obvious to me, but not to everyone, that such hidden changes to messages should never happen by default. Its not good enough for someone to think its good and force it on others, or to decide that certain elements of other people's messages, such as the exact location of each character, are unimportant and can be messed with by default. There should not need to be an argument for turning off format=flowed when sending a message. The argument should be about why it should be on by default. I don't think it should be. Please see my contribution to Bug 71110 regarding the interpretation of format=flowed messages, which I argue should be off by default. Likewise, for a plea to keep Mozilla clear of all the default mangling and smartypants featuritis which plagues too much software these days, please read my contribution to Bug 88986 on those vertical bars instead of "> ". Its simple: keep everything simple and straightforward by default - so that what the sender writes and sees is by default conveyed, *precisely* (no bolding, no graphic smilies, no rewrapping and no vertical bars), in a fixed width font at each end, to the recipient, with sensible 72 column or less automatic WYSIWYG wrapping of text as the sender types. It should not be necessary for people who want format=flowed to be off by default to be fighting a belated battle to have such automatic default mangling of messages removed. Nor should it be necessary to argue against notions such as the precise layout of characters in a message is unimportant and by default should be altered in some way. The exact characters and exact position of the text written and seen by the sender are innocent until proven guilty. Please just make Mozilla behave simply and clearly, by defaulting to plain text sending of messages, without format=flowed, and to default to displaying such messages precisely as they were written. Life is complicated enough without computer systems invisibly (to the sender) altering communications by default. - Robin http://www.firstpr.com.au
> keep everything simple and straightforward by default Please use telnet to read and write mails. This is offtopic, see <http://bugzilla.mozilla.org/show_bug.cgi?id=88986#c2>.
Ben, you wrote: > Please > use > telnet > to > read > and > write > mails. No. I want to use Mozilla! I think its bad ettiquette to imply that other people who want to use Mozilla and want to contribute to it being a fabulous program for millions of people should forget about it and use something else just because they disagree with one of your ideas. As I argued here, in bug 88986 and in bug 71110, I believe that by default, format=flowed should be off when sending messages, and that there should be a GUI user option, with appropriate explanatory text, to enable people to turn it on. Your support of default-on format=flowed for outgoing messages, with no GUI option for ordinary mortals to turn it off, amounts to you foisting format=flowed on every outgoing message for every future Mozilla user. This is millions of people, writing billions of emails, spending the equivalent of tens of thousands of human lifetimes crafting their messages to be how they want the recipient to see them. The last thing they want is some hidden alteration to their message in the email system! Your suggestion forces upon all those people, and their recipients, a situation where the message received by the person at the other end, on screen, is laid out differently from what the sender crafted and intended them to see. If your wish was granted, as it currently is, then your wish disrupts the communications of vast numbers of people. Its not good enough to say that linewidths are unimportant to communication. You should let other people decide what is important to their communication and not impose any enhancement / transformation / mangling by default, or by giving them no other option. Line widths and layout are important. I am sure you will agree, after seeing your own writing coerced into a line length other than what you intended. - Robin
Robin, debating format=flowed is *not* the point of *any* bug in BugZilla, as BugZilla is *not* a debating tool, but a bug tracker. Use the netscape.public.mozilla.* newsgroups instead (in this case, n.p.m.mail-news). And copying your comment to three bugs doesn't really help "spread your message".
taking all of varada's bugs.
Assignee: varada → sspitzer
Mozilla posts stand out in the newsgroups that I frequent becuase they are the only ones that are format=flowed. It really does not matter how supperior that some feel that the format is, the composer of a message should have the option to compose and send their message in a pure plain text mode. The big problem with format flowed is that I hit the carriage return key by habbit when I see the cursor approaching the margin. When the lines are edited, they autowrap. So while the e-mail or the news posting looks properly formatted when I send it, it looks like garbage when it is read by a newsreader that understands format=flowed. Microsoft Exchange users are having a similar problem trying to get "Quoted Printable" disabled.
Blocks: 168420
People interested in this bug / request for enhancement may be interested in two other bugs: 1 - Bug 141983 "Space added to indented line when sending or saving message" This is a 1 year old bug which I have just shown to be caused by the "format=flowed" code when sending and saving messages. This is a showstopper for many people. For a year this bug has stopped me from using Mozilla for email, which means I only use it for HTML editing. 2 - Bug 204437 "Format=flowed gobbles 1 space in indented lines" An equal and opposite bug to the one above, which removes one space from all indented lines in "format=flowed" messages. This may not be a showstopper, but like the first one it involves alteration or incorrect display of the message. Both bug pages show user.js preferences for turning off the two features and therefore working around the bugs. Until the second bug was revealed, there was no reason for any of us to think that the first bug had anything to do with "format=flowed". We all thought it was in the serializer, or later jfrancis said it was in the DOM to text conversion code (maybe that's a similar thing?). In this instance, adding a new complicated function and turning it on by default obscured the fact that the bug was in the new feature - for a year. Had the sending "format=flowed" feature been off by default, then whoever turned it on would have found the extra space bug and thereby have had good reason to believe the bug was in the "format=flowed" code. Since both these "format=flowed" features (even without their bugs) have the potential to make messages appear different (in terms of line lengths and breaks) to the way the sender wrote them, I believe they should both be off by default, with well-explained user interface options to turn them on. Bug 168420 "We need Format=Flowed Evangelization" also discusses these issues and links to a number of related bugs. - Robin
As much as I agree with Ben on the desirability of f=f, I do not agree that there should be no UI to control it. By digging in his heels here, he is matching Robin tit-for-tat in zealotry. - f=f display: there are two issues that seem to be real here: some people prefer the > prefix rather than the excerpt bar (bug 88986); and some people, myself included, would like to limit the width of the reflowed lines to some maximum (bug 71110, which is not even specific to f=f). Disabling reflow for a message sent with f=f really is not too sensible, if these other issues are addressed. - f=f transmission: Ben conceded (long ago, over in bug 141983 comment 21) there was a case where formatting a message as f=f could interfere with the message's purpose: this is the case where the message is a patch or other text intended for a computer program. I would like to see this preference made per-account, as requested in bug 98397, and I don't think having a checkbox on the account's Compose Settings page would be that onerous. It should definitely default to Enabled. I would *also* like to see an item in the compose window's Options menu which allows f=f to be turned off for that particular message; it would default to the setting for the account under which the message is composed. This would allow the occasional sending of ASCII art without having to worry about space- stuffing. I grant that most people will look at these options and say, Huh? The options will be little used; but also little used is the menu on the Compose window for changing the character coding. For the people who need it, it is very useful.
If I am composing a message in format-flowed, it should be displayed in the width of the window, as a receiver of a client that knows format flowed would see it. Right now, the implementation is that what I see in the compose window is not what will be seen by the receiver. There is no way to visibly tell the difference between a carriage return that I enter, and a line wrap that Mozilla inserts. With out the ability to at least turn on an indicator of the line wrap, or veiw as a client would see it, the format flowed as implemented causes too many invisible formatting problems, and I would disable it completely if I had that option.
> If I am composing a message in format-flowed, it should be displayed in the > width of the window Agreed, but not subject of this bug.
Agreed, the display of line wraps is a separate enhancement. Submitted as 232750. With out this feature, having format flowed the only text sending format is flawed.
Product: MailNews → Core
*** Bug 322210 has been marked as a duplicate of this bug. ***
*** Bug 332512 has been marked as a duplicate of this bug. ***
*** Bug 353957 has been marked as a duplicate of this bug. ***
I found this bug report by searching for "plain text word wrap" and was surprised to find status=NEW despite the fact that it was opened in 2001. This may be to do with the change of sspitzer's email address). I also found the discussion so far rather confusing, so I'll take it from the top. I've just tested the effect of "wrap plain text at 30 characters" in T-bird 1.5.0.8 by sending myself a message: * It wraps to 30 in the Compose window. * In the Sent folder's Message pane it displays one line at full width, then 1 word, then the rest of the message in 1 line greater than 30 characters but less than the width of the pane. * In the Inbox' Message pane it displays one line at full width (but 1 word shorter than in Sent), then 2 words, then the rest of the message in 1 line greater than 30 characters but less than the width of the pane. * When I opened the message from Inbox, it wrapped only at the full width of the window. * In print preview it wrapped only at the margin. It looks like T-bird is as confused as I am. I think we need to look at this mainly from the recipients' point of view: * Word-wrapping all plain text messages at a fixed width (which T-bird 1.5.0.8 requires - see Tools->Options->Composition->General) makes the message look horrible both on screen and in print if the container (window, pane, paper) is narrower than the specified width - every second line contains only a very few words. * Some recipients (especially some newsgroups) require plain text not exceeding X characters per line. So I suggest: * Scrap the global fixed width requirement. So in most cases the text will flow in all views until the writer hits Return. * Provide a "word wrap at X characters" option in the Address Book, default it to empty, do not force word wrap if this field is left empty. * If some addressees have "word wrap at X characters", display the message in the Compose window at the lowest value of X found in the set of addresses. This will enable the writer to check that e.g. tables or ASCII art do not contain unwanted word wraps. * Re-flow the message in the Compose window if the set of addressees is changed. * When the user hits Send, use the lowest value of X if there is a non-empty value for any addressee. Insert a hard carriage return at the end of each line. Then send. I hope this will ensure that the sender and all recipients see the same word-wrapping in all views. The other major issue I picked up from the discussion is that some people have large monitors at high resolutions and don't like reading very long lines. My thoughts on this: * There should be no problem in print views. * The Compose window and the window shown when you open an incoming or sent message can easily be re-sized, and T-bird remembers the size of these windows when they were last closed. So I think they are no problem. * That leaves the Message pane in the main window. Users with large monitors at high resolutions are likely to size the main window to show the information they want in the folder contents pane (e.g. all items in Inbox). So there is a problem with line lengths in the Message pane only if the user's preferred line length is a lot shorter than the desired width of the folder contents pane. Is this very likely or very serious?
Turning off format=flowed is necessary for proper use of digital signatures via PGP or GPG. See bug #363302. For Thunderbird, this should be part of the user interface, either under [Tools > Options > Composition] or (better) specific to each account under [Tools > Account Settings > [account name] > Composition & Addressing]. Users should not have to go to [Tools > Options > Advanced > Config Editor] and then try to remember which preference variables to toggle (and remember that two -- not one -- variable is involved).
(In reply to comment #32) > I think we need to look at this mainly from the recipients' point of view: > * Word-wrapping all plain text messages at a fixed width (which T-bird 1.5.0.8 > requires - see Tools->Options->Composition->General) makes the message look > horrible both on screen and in print if the container (window, pane, paper) is > narrower than the specified width - every second line contains only a very few > words. Yes. But there is no valid solutions: if you try to automatically reformat text, you always may find texts, which will be broken )for example, tables, sources or ASCII art). > * Provide a "word wrap at X characters" option in the Address Book, default it > to empty, do not force word wrap if this field is left empty. _I_ expect, that _all_ my mails will be _text_, with explicit line breaks at given position (unless line contain no spaces to break at it). I not expect to manually edit all addresses options, especially most used addresses are cached automatically. > * Re-flow the message in the Compose window if the set of addressees is > changed. Which re-flow you mean with "f=f" disabled?!
> But there is no valid solutions: if you try to automatically reformat > text, you always may find texts, which will be broken )for example, tables, > sources or ASCII art). f=f differentiates between lines/paragraphes which are allowed to be wrapped and those which are not, for exactly that reason. > _I_ expect, that _all_ my mails will be _text_, with explicit line breaks > at given position It seems we have a different idea about what "text" is. For me, "text" means wrapping lines. The same goes for most other, non-geek people. If you have a different opinion, you have <about:config> to change the behaviour, which is perfect for geeks.
> > But there is no valid solutions: if you try to automatically reformat > > text, you always may find texts, which will be broken )for example, tables, > f=f differentiates Please, note how this thread/report titled: "_disabling_ f=f". > > _I_ expect, that _all_ my mails will be _text_, with explicit line breaks > > at given position > It seems we have a different idea about what "text" is. For me, "text" means > wrapping lines. For me too. Difference is when and at which point wrapping happen - and with f=f there (in TB) are too many headaches with wrong text handling. > The same goes for most other, non-geek people. If you have a > different opinion, you have <about:config> to change the behaviour, which is > perfect for geeks. Please, note how this thread/report titled: "_disabling_ f=f". "UI option".
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: olgam → composition
Product: Core → MailNews Core
7 years old bug and still not resolved??? US congress is more efficient.
Summary: [RFE] UI option for disabling format=flowed → UI option for disabling format=flowed
I'd like to make an impassioned plea for this feature. I have used Thunderbird since it was Netscape Messenger; it's been my only email client for a very long time. I use it heavily; it is my primary work function. The lack of a user visible option around the flowed option caused me major dismay, which I have only today come to understand. That is, I prefer to use plain text email; and I prefer to control my own formatting. I take great pride in the presentation and visual appeal of my fixed text messages. For years, I sent my own nicely formatted emails, and life was good. But I started noticing with Thunderbird, particularly newer Thunderbird, that my nice little world was crashing down. I was seeing evidence in the quoted replies that apparently I'd sent out sloppy, mis-formatted emails. I spent a day once, trying to figure this out. Now I wasn't clever enough to fully grok the format=flowed issue, and could never figure out that it was, in fact, the setting that was causing me grief. (I did discover that Thunderbird was adding 'format=flowed' to all my emails, and was deeply suspicions, but never found my smoking gun). I finally gave up, and turned everything back to Thunderbird defaults; wrapping at line 72, not ever doing hard line ends. I lost a cherised ability - the ability to hand format my emails. I've spent this past year, sad and lonely, and was getting ready to ditch my beloved Thunderbird *on this issue alone*. Recently, I've had cause to research this again, and I think I've finally found the explanation for what I was experiencing: https://bugzilla.mozilla.org/show_bug.cgi?id=477541 So, I'm not a zealot, I use Thunderbird all day every day in what I like to think are 'normal' ways, and the lack of this user visible option just about turned me away from Thunderbird forever. I understand that you can make a rational argument that, once this bug is fixed, then flowed will really be okay and no one will want to turn it off. It just seems to me that something that is performing a non intuitive transformation on my email should be exposed in the user preferences; I should have had a clue in the GUI, imho. Thanks for listening. </soapbox>
For those interested, there's a Toggle Word Wrap extension: https://bugzilla.mozilla.org/show_bug.cgi?id=86607 It provides dynamic enabling/disabling of the automatic word-wrap and its latest version (1.4) suppresses sending in format=flowed when word-wrapping is disabled. I've mailed the author a patch to make it compatible with SeaMonkey 2.0, also.
(In reply to comment #41) > https://bugzilla.mozilla.org/show_bug.cgi?id=86607 Nice. It is obviously the wrong link. Here's to correct one: https://addons.mozilla.org/en-US/thunderbird/addon/2351/
Given the presence of the extension maybe this can be closed?
In reply to comment 44, how is that suggestion helpful?
Can't test with seamonkey - seamonkey is unsupported. But in addon description pointed to html <pre> tag, and no one word about format=flowed.
It's not clear from the description, but if that extension disables f=f at all, it's only when word wrap is disabled, which is no use.
(In reply to comment #46) > Can't test with seamonkey - seamonkey is unsupported. Sure it is <https://addons.mozilla.org/en-US/seamonkey/addon/2351/>: Version 1.5 July 4, 2010 Works with: * Thunderbird 1.5 - 3.2a1pre * Firefox 1.5 - 4.0b2pre * SeaMonkey 2.0 - 2.1a3 - add support for Seamonkey 2 ... (In reply to comment #47) > It's not clear from the description, but if that extension disables f=f at all, > it's only when word wrap is disabled, which is no use. Yes, using the given extension f=f gets disabled only sending when word wrap is disabled, and one needs to manually Edit -> Rewrap. This issue needs a better solution - see also Bugs 204478, 475712.
See also bug 534068. The ability to turn off word wrap and f=f is required when sending source code patches for projects such as the linux kernel. It would be really nice to have a "raw" or "preformatted" option for text-only (i.e. non-html) email that would send it out *exactly* as it was composed. Ideally I should be able to copy a patch file, paste it into my email, and have it remain a valid patch on receiving clients that don't support f=f.
As a followup, I just tried the extension and it sort of works for the purposes of sending patches. However, it would be better if anything already written and auto-wrapped in the composition window would be hard-wrapped at the same spot when disabling f=f so that a manual rewrap isn't necessary.
Whiteboard: mailnews.send_plaintext_flowed = false
(In reply to comment #49) > Ideally I should be able to copy a patch file, paste it into my email, and have > it remain a valid patch on receiving clients that don't support f=f. If you already have it in file form, why isn't attaching the file preferred?
Maybe, not a file, but somethink like hg diff|thunderbird -compose ang obtain new mail window with mail body filled with diff
Several of the core linux kernel developers insist that patches be inline rather than attached, to the point where attached patches may get ignored completely. It's just part of the culture. Because of that, it is necessary to have some way of sending emails with no wrapping, no f=f, no nothing. Basically, it needs to be sent *exactly* as written. To Igor...is that form of the "-compose" option actually supposed to work? Don't you need to specify the "body" field?
Sad, but currently I don't know away to get body from stdin. So, I hope it will be possible in future, bcouse it's useful for mailing script results, after some manual tuning, and have sent mails in mail archives.
If patch submission is restricted like that (must be msg body), wouldn't it make more sense to use a tool designed for a *nix command line, like mh, to perform the mailing? To be clear: I am in favor of better control over f=f, even beyond UI for the existing prefs, as I noted in comment 25. But I don't expect to ever see it; I'm certainly not going to write it. There are far greater problems in this codebase going ignored by the current Let's-Make-It-Look-Flashy regime.
Patches are often submitted to the kernel mailing list as part of a discussion thread, not just as standalone entities. The patch may even be in the same message as a standard english response to some previous comments. Thus, it is useful if one's normal email client is capable of sending patches as well.
Yes, we shouldn't tell users to go away :). That said, I think kernel developers are fully capable of using <about:config> (or Prefs|Advanced|Config Editor...) instead of a [ ] Flowed checkbox. In fact, I argue that a pref that's called for mainly by kernel developers and similar kinds of users *should not* have UI, because any additional UI widgetry makes the app less usable for normal users.
Ben, While it may be true that any additional UI widgetry makes the program less usable for most people, "ordinary users" or whatever, it is also true that anything the program does which is unexpected has the same effect. This is particularly so if the unexpected behaviour can't be altered once it occurs - as it is in this case, with the recipient getting something different from what the sender thought they were sending. This problem is worse still because it affects the core functionality of the program - sending messages. The ill effects of the current state of format=flowed persist indefinitely in private emails and mailing list messages which look sloppilly written, and which are harder to read. When people compose a message, including with whatever leading whitespace and character positions they choose, they have a reasonable expectation that this will be conveyed to the recipient without any changes. So sending with format=flowed should be off by default. You may never attribute any meaning or significance to the length of lines, the whitespace at the start of lines etc. but some folks do. This debate has been going on for nearly 9 years. A number of people have written here that the current arrangement of format=flowed being on by default causes significant trouble. I believe HTML sending should be off by default, since HTML email causes so much trouble. But if people select non-HTML, previously "plain text" composition, the program should send what they see in the compose window. Failing that, there should be a UI option for disabling sending with format=flowed. Yet you argue against even a UI to turn of the default format=flowed sending, because an extra button somewhere would degrade usability for "normal users". That would be a tiny fraction of the degradation caused by the currently hidden state of default-on format=flowed, such as the trouble reported above by Philip Chalmers. The plug-in https://addons.mozilla.org/en-US/thunderbird/addon/2351/ "Toggle Word Wrap 1.5" may be helpful for people who are wise to the problem and motivated to install a plug-in. However, plug-ins are a lot more trouble, for those who use them, than a UI option in the program itself. Robin Whittle
> So sending with format=flowed should be off by default. Not subject of this bug. The arguments are all known. Some are false (like "send exactly what is written", as that can never happen, see e.g. QP, ">From" and similar). It has been decided that we will support format=flowed, even though some people don't like it. They are in the vast minority, although very vocal. Please note that format=flowed-mail readers show the msg 'as written'. You can ask the other mailers to support the format=flowed standard, at least on the *reading* side. That's not hard, and it's useful. Given the mimetype subtype, the reading MUA can unquestionably tell which msg is format=flowed without altering other plaintext msgs. > can't be altered once it occurs It can. And for the mentioned user groups fairly easily. That was my point. If spaces break your message, you are likely to be an advanced user who has no problem using <about:config> and Google to find a solution. > This debate has been going on for nearly 9 years. Yes, and it's useless. Please do not debate, thank you.
Ben, You assert that format=flowed does not change the message, but other people who have written here attest that it does - and that the changes have a negative impact on the readability of the message in various contexts. The sender writes and formats their text on screen and unless we know they think like you, I and other people believe the program should work on the assumption that they expect to have their message appear to the recipient as they saw it when they wrote it, including in terms of spaces, indentation and margins. You assert this is an unreasonable expectation. I and others assert it is for the sender to decide what matters in their message - not for you or someone else to discount the existence of meaning they encode in spaces and the beginnings and endings of lines. We assert this, in part, for the purely practical reason that we have observed and experienced format=flowed disrupting communication. The ">From" change is a violation of this principle, but is a much rarer and more minor problem than the changes caused by format=flowed. You assert the people who believe format=flowed sending being on by default, and hard or impossible to disable by the UI are in the minority. The debate may well be useless in terms of changing your thinking, but I see no reason to accept your assertions as being the truth, or to accept your request not to "debate" - meaning not to write things here which are contrary to your views. - Robin Whittle
It would also be enough, most of the time, if replying to a non-f=f message left f=f disabled.
Ben, Your main argument against this seems to be that "advanced" users should not ask for an UI option in an UI application?! That just doesn't make any sense, sorry. How could adding functionality (and we're only talking about one UI option hidden in some settings menu here) make an whole application less usable? According to you, "normal" users don't need the option, so why would they go looking for it? This request was made because some people (passionately) feel it's needed. Why not support the UI option even if you don't like it? Instead of making this about "groups" or f=f itself, why not evaluate request on its real merits? Such as usability, for one. Robbert
The transmission of software patches and the formatting of tables are not the only things adversely affected by format=flowed. Using an OpenPGP application, verifying a digital signature on an E-mail message requires that any bit of the message not be altered after it was signed. This is part of the integrity verification, to assure the recipient that the message that was received is indeed the message that was sent.

19 years later there is an option to turn off format_flowed for the UI representation, but I don't understand why Thunderbird doesn't follow the WYSIWYG concept per default.

You write a wonderful text block based plain email and send it. This part is done perfectly by Thunderbird with the default settings (72 chars, flowed for mobile compatibility on). But when you look at it again in the Sent folder or if the recipient runs Thunderbird with default settings you see a nearly unreadable mess of very long lines followed by double line breaks.

Only after setting mailnews.display.disable_format_flowed_support to True in about:config you see what you composed once.

Gmail shows the mail as it was composed. Apple Mail on the laptop handles it like Thunderbird. So at least Thunderbird isn't alone.

Doesn't it make sense to set mailnews.display.disable_format_flowed_support automatically based on the window width or make it default given the fact that Thunderbird is a program that mainly runs on large screens?

Gmail shows the mail as it was composed

No. They do not. See e.g. https://mathiasbynens.be/notes/gmail-plain-text
Every email program mangles emails in some way or other. Because they have to, for technical reasons. Plaintext cannot transport what you typed, exactly as you typed it. Particularly, soft linebreaks will be lost and lines consequently reformatted.

You write ... with the default settings (72 chars, flowed

Even if you see in your Sent folder the same thing that you typed, doesn't mean that your recipient does.

E.g. your recipient has a mobile phone, and does not have 72 chars wide screens. Or he has a large desktop screen and has 150 wide windows. You have no idea how your recipient will read the email. If you force it on him, you may well make it unreadable for him. To prevent that, many email clients will reformat plaintext, even if you try to force a line width. Because the user might simply not have 72 char wide screens.

That's why some mail readers change the plaintext linebreaks even more drastically and less predicable than format=flowed. format=flowed is precisely and well defined what should happen. It distinguishes between soft and hard line breaks.

why Thunderbird doesn't follow the WYSIWYG concept per default.

Because there is no such thing in email. You might think so, but in reality, different clients do line wrapping differently, quoting and line wrapping in quotes, "From " at the start of the line is escaped due to mbox, etc.pp. And I'm not even starting with UTF-8 character sets, quoted-printable, and so on. It gets very much into technical details and implementation specifics of common email programs quickly, but plaintext is not WYSIWYG at all.

Esp. the line wrapping gets messy really quickly.

format=flowed solved actual technical problems, which messed up plaintext emails really badly.

f=f does what most people need for emails. It may not be what you want, or even your friends need, but what most people want. So, you can change the settings, you get what you want, and everybody is happy.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME

Hi Ben,

19 years later and you are still around. That's passion.

No. They do not. See e.g. https://mathiasbynens.be/notes/gmail-plain-text

They do it in the WebUI (Fullscreen), I tested it two times by sending an different flowed text email to Gmail and looking at it in the Inbox.
Every line break is there. In the Inbox of Thunderbird it's the expected mess for the same email.

f=f does what most people need for emails. It may not be what you want, or even your friends need, but what most people want.

Following this logic Gmail would do it that way as well because it's by far the biggest mail provider. But they don't.
Don't get me wrong I'm not questioning f=f, the send behaviour of Thunderbird or any other standard. I'm talking about the default and static UI representation of flowed text mails.

Because there is no such thing in email (WYSIWYG)

Well at least this problem is gone when using html. It seems to follow the WYSIWYG concept much more.

I know that you have your very strict opinion and that's perfectly fine for me.
Just wanted to let you know that there are still people who question this.

Cheers

19 years later and you are still around. That's passion.

Thanks. Yes, it is!

sending an different flowed text email to Gmail and looking at it in the Inbox

You're sending it to yourself, and read it in the same client as you typed it. You might see it the way you typed. Your recipient might not. The WYSIWYG is an illusion that's true for you, but not for your readers. I argue that's even worse, because deceptive. Nobody has ever coherently defined how plaintext email is supposed to work, and requirements evolved a lot over time, and each client adapted in its own way. You cannot be sure how your recipient sees your email.

format=flowed cleans a lot of this up and clearly specifies what should happen in which case.

html. It seems to follow the WYSIWYG concept much more

HTML isn't WYSIWYG, either. It's been semantic since its inception, and specifically not for layout. CSS would be for layout, but even that specifically allows clients to adapt rendering. The renderer adapts the page to the device, including line breaks. HTML also has soft line wrapping by default, like format=flowed.

format=flowed has both soft and hard line breaks. If you want to type a hard linebreak, just press ENTER on your keyboard in the Thunderbird editor. The default is soft wrapping, which is what most people want 95% of the time.

You don't like that, and that's fine, so you can disable it.

You're sending it to yourself, and read it in the same client as you typed it

Just to be clear with the Gmail example. No I don't do this. It wouldn't proof anything as you said.

I type the email (text flowed) in Thunderbird and send it from there (different email server, no text manipulation) to Gmail.
Then I look at the email in the Gmail WebUI Inbox and Thunderbird Sent folder (or Inbox when having myself in CC).
Gmail WebUI handles every soft line break as line break, Thunderbird doesn't.

The URL you posted above is from 2014. Maybe you expect Gmail to do something completely different than it does now.

f=f seems to solve problems that no longer exists, and add new existing problems. In 2022, I have difficulties seeing why anyone would enable it, and why it is enabled by default. Even in the 90-ties my mail readers supported soft wrapping.

I don't take a position in this debate. Just correcting the resolution since this bug's request (for an UI option) was denied in comment #65.

Resolution: WORKSFORME → WONTFIX
You need to log in before you can comment on or make changes to this bug.