86607 - UI option for disabling format=flowed

Status: NEW

Description

[Holger Metzger]

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.

Comment 1

[Boris Zbarsky [:bzbarsky, bz on IRC]]

See bug 71110. I think it would fix the problems you're having...

Comment 2

[Holger Metzger]

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.

Comment 3

[Sheela Ravindran]

change qa contact ->ninoschka

Comment 4

[Jean-Francois Ducarroz]

reassign to varada

Comment 5

[Keyser Sose]

Marking NEW.

Comment 6

[Ben Bucksch (:BenB)]

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.

Comment 7

[Holger Metzger]

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.

Comment 8

[Ben Bucksch (:BenB)]

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

Comment 9

[Holger Metzger]

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

Comment 10

[Daniel Bratell]

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

Comment 11

[Ben Bucksch (:BenB)]

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

Comment 12

[Holger Metzger]

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

Comment 13

[Jean-Francois Ducarroz]

reassign to varada...

Comment 14

[Frank Widmaier]

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. <[e-mail]>

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"

Comment 15

[Todd M. Lewis]

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.

Comment 16

[Ney André de Mello Zunino]

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

Comment 17

[Ben Bucksch (:BenB)]

Ney, I agree, see comment 6, where I referenced bug 71110.

Comment 18

[Robin Whittle]

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

Comment 19

[Ben Bucksch (:BenB)]

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

Comment 20

[Robin Whittle]

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

Comment 21

[Sören 'Chucker' Kuklau (gone)]

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

Comment 22

[(not reading, please use [e-mail] instead)]

taking all of varada's bugs.

Comment 23

[John Malmberg]

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.

Comment 24

[Robin Whittle]

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

Comment 25

[Mike Cowperthwaite]

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.

Comment 26

[John Malmberg]

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.

Comment 27

[Ben Bucksch (:BenB)]

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

Comment 28

[John Malmberg]

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.

Comment 29

[Magnus Melin [:mkmelin]]

*** Bug 322210 has been marked as a duplicate of this bug. ***

Comment 30

[Jo Hermans]

*** Bug 332512 has been marked as a duplicate of this bug. ***

Comment 31

[Mike Cowperthwaite]

*** Bug 353957 has been marked as a duplicate of this bug. ***

Comment 32

[Philip Chalmers]

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?

Comment 33

[David E. Ross]

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

Comment 34

[Arkady Belousov]

(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?!

Comment 35

[Ben Bucksch (:BenB)]

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

Comment 36

[Arkady Belousov]

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

Comment 37

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 38

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 39

[Wei]

7 years old bug and still not resolved???

US congress is more efficient.

Comment 40

[Jeremy White]

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>

Comment 41

[Stanimir Stamenkov]

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.

Comment 42

[Stanimir Stamenkov]

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

Comment 44

[Paolo Bonzini]

Given the presence of the extension maybe this can be closed?

Comment 45

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 44, how is that suggestion helpful?

Comment 46

[Igor Velkov]

Can't test with seamonkey - seamonkey is unsupported.
But in addon description pointed to html <pre> tag, and no one word about format=flowed.

Comment 47

[Roger Lynn]

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.

Comment 48

[Stanimir Stamenkov]

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

Comment 49

[chris.friesen]

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.

Comment 50

[chris.friesen]

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.

Comment 51

[Mike Cowperthwaite]

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

Comment 52

[Igor Velkov]

Maybe, not a file, but somethink like 

hg diff|thunderbird -compose

ang obtain new mail window with mail body filled with diff

Comment 53

[chris.friesen]

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?

Comment 54

[Igor Velkov]

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.

Comment 55

[Mike Cowperthwaite]

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.

Comment 56

[chris.friesen]

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.

Comment 57

[Ben Bucksch (:BenB)]

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.

Comment 58

[Robin Whittle]

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

Comment 59

[Ben Bucksch (:BenB)]

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

Comment 60

[Robin Whittle]

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

Comment 61

[Paolo Bonzini]

It would also be enough, most of the time, if replying to a non-f=f message left f=f disabled.

Comment 62

[Robbert Eggermont]

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

Comment 63

[David E. Ross]

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.