Closed Bug 448706 Opened 14 years ago Closed 14 years ago

Remove "Wrap plain text messages at..." from prefs


(Thunderbird :: Preferences, enhancement)

Not set


(Not tracked)

Thunderbird 3.0b1


(Reporter: sha256sum, Assigned:




(1 file, 1 obsolete file)

4.65 KB, patch
: review+
: ui-review+
Details | Diff | Splinter Review
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008071615 Fedora/3.0.1-1.fc9 Firefox/3.0.1
Build Identifier: 

I think "Wrap plain text messages as ... characters" is more a Formatting feature than a Composition feature.

I therefore propose it is moved to Display->Formatting.

See mock up.

Reproducible: Always
Attached image Mock up (obsolete) —
No, that option affects the composed message (when viewed as source or in a client that does not support format=flowd), and the display while composing only incidentally.
Closed: 14 years ago
Resolution: --- → WONTFIX
Blocks: 448716
Arguably, the pref ui element in question should be removed, as it's really a legacy client compatibility option with a sane default, and it's probably not understood to be that by most people who might happen to change the sane default to something that makes messages appear badly in receiving clients without format=flowed support. The setting does not affect the appearance of messages sent by thunderbird when viewed in thunderbird outside composition (unless prefs without any ui are changed), which is pretty nonsensical behavior.
I always wondered at what logic caused it to default to 72
Maybe that's a full screen for 800x600 (which hardly anybody uses anymore)
I long ago set that at 255 for a longer line for plaintext newsgroups.

Well, it does matter occasionally, for instance in some mailing list management situations where commands are one per line and wrong wrapping makes it not work at all. And then it of course makes a difference when the receiver doesn't support format flowed. I kind of doubt 255 is very reasonable, even if it likely doesn't matter much for most users, which also makes the source not pretty;)
Actually, I'd like to boot this ui from the prefs.  I think sp3000 is making a great point that this is legacy UI with a sane default which makes much less sense today than it did when it was first introduced.

If the default is reasonable then we can remove it from the prefs the option would still be configurable from the about:config editor.
Resolution: WONTFIX → ---
Summary: Move "Wrap plain text messages at..." to Formatting → Remove "Wrap plain text messages at..." from prefs
Even though I'm using plain-text composition by default for years now, I don't recall having ever touched that setting. The length of 72 (maybe derived from the historical maximum Fortran line length?) fits well, and that preference is to a certain extent obsolete by the f=f mechanism introduced later. Admittedly, f=f is not supported by all e-mail clients yet, but the wrap option would only truly make sense if there were also a UI element for enabling or disabling f=f when composing messages (which would also be useful when replying to non-f=f messages, e.g., from Outlook, which may contain trailing white spaces).

Also, cases are frequently seen in the forums where users try to apply that option in HTML composition mode, where it doesn't have any impact until the message is sent with a text/plain MIME part. Thus, if that option is retained in the UI, it should probably move into the more advanced pref areas, or into the composition window itself, and possibly accompanied by f=f checkboxes.

Magnus, how significant would you see your example stated in comment #5, which seems to be a rather special case of requiring a certain wrap setting? Maybe a wrap/no-wrap option in the composition window would be more beneficial to accommodate such case?
Well, f=f doesn't mean we don't wrap the source. 
(But no, I don't think my note is a significant use case.)
You are right, f=f and wrapping are two different things, but certainly related. My thinking was that one would expect the following basic plain-text cases:

1. Normal text with a "flowed" format, thus wrapping and f=f activated;
2. preformatted text that should neither be wrapped nor sent with f=f;
3. text should be wrapped but not sent f=f (as preferred by some users).

The 72-character default line length should be fine as a default, that's about the value used and expected by other e-mail clients as well. The wrap/no-wrap functionality may be a separate bug, or could be combined with bug 86607 and any related other wrapping bugs.

Confirming this as a valid request and supporting statements to remove its UI.
Ever confirmed: true
Hardware: PC → All
Version: unspecified → Trunk
Attached patch Proposed patchSplinter Review
No objections were voiced against removing the UI for this pref,
so here is the patch.
Assignee: nobody →
Attachment #331879 - Attachment is obsolete: true
Attachment #343654 - Flags: ui-review?(clarkbw)
Attachment #343654 - Flags: review?(philringnalda)
Comment on attachment 343654 [details] [diff] [review]
Proposed patch

Great, looks good to me
Attachment #343654 - Flags: ui-review?(clarkbw) → ui-review+
Attachment #343654 - Flags: review?(philringnalda) → review+
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b1
Ah yes, now I remember why I changed that pref to 255 (better late than never)
It was so that I could see how a plaintext message would appear as I was composing in a 1024x768 window.(WYSIWYG for that resolution)
I just do hard line breaks on the right side.
So for a default of 72 to get the same appearance, I would have to continue to type past the 72 char default, and what...count the characters?
Well anyway, I guess that pref is still there in CongigEdit

What exactly is the format of that pref.
Sorry for the spam,
mailnews.wraplength not very intuitive, at least for me (html compose 95% of the time)
Thanks to Bryan and Phil for the quick reviews and for checking in the patch.

Joe, mid-air collision with my response, here the explanation anyway:
With mailnews.wraplength set at its default 72, and composing a plain-text message, it simply means that a line cannot have more than 72 characters before an "f=f" line break is inserted (or a hard line break if you disabled flowed format). If the receiving client does not support f=f, this is how it will be displayed there (WYSIWYG in this case); if it does support f=f, there is no WYSIWYG as the recipient may have a different window width fitting more or less than 72 characters. If you set it to 255, it will be sent out with that many characters (some relays truncate or split overly long lines, by the way...), and may not fit into a smaller window unless f=f is supported.
You need to log in before you can comment on or make changes to this bug.