166356 - Line breaks shown during message composition should match what is posted

Status: VERIFIED WORKSFORME

(MailNews Core :: Composition, enhancement)

Description

[Jonadab the Unsightly One (Nathan Eady)]

# 14) Try to respect the 80-character line-length conventions
# 
# Any line breaks shown to the user while she is editing her article
# SHOULD still be present when the article is actually posted to the 
# Net.  The software SHOULD NOT show the user four 75-character lines 
# while actually posting a single 300-character line.  Nor should it 
# show the user a series of 100-character lines while actually posting 
# alternating lines of 80 and 20 characters each.
# 
# It's also a good idea to warn the user if the article she is about 
# to post contains non-header lines longer than 80 characters.  The 
# software SHOULD NOT prevent the posting, but SHOULD ask whether the 
# user wants to re-edit or post anyway.

Please note that clients are not required or expected to understand
format=flowed, since none of the email or usenet RFCs make reference
to it.  (It has its own RFC, but the email and usenet RFCs do not
reference it, AFAIK.)  The line breaks shown to the user during
composition need to be included as such in the posted text.

Comment 1

[Boris 'pi' Piwinger]

Not sure this is an enhancement. There are already bugs about how to handle this
format flawed and the related problems. Not sure if and where to dupe it.

pi

Comment 2

[Mike Cowperthwaite]

If the receiving client does not support f=f, then the line breaks seen in the 
received message in fact *are* the line breaks seen during compose time (for 
plain text compose, that is).  Mozilla does not create long lines of text in the 
sent source.

If the original message contains long lines, then (unless that original message 
is f=f and can be reflowed in the quoting process) the long lines will be quoted 
as long, and will not wrap in the compose window.  They can be rewrapped 
manually from the Edit menu.

There certainly are bugs in the f=f implementation; see the f=f tracking bug 
168420.  However, from the plain text editor, the line breaks seen in the window 
are exactly the line breaks sent.  Reflowing occurs on the client side, if at 
all.  (Perhaps that behavior was different when this bug was originally filed.)

The exception is if the hidden preference   mail.compose.wrap_to_window_width
is set to True.

Comment 3

[Ben Bucksch (:BenB)]

verified.