User Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0 Build ID: 20130104151925 Steps to reproduce: Set mail.wrap_long_lines to false Actual results: New post still get wrapped Expected results: It should not wrap unless I enter a CR manually
Set mailnews.wraplength to 0 will get the unwrap effect. So it seems mail.wrap_long_lines is no longer used. Does it mean this bug is invalid?
Some of those prefs apply only to plaintext composition See this article for more info http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29#Flowed_format
I also read http://kb.mozillazine.org/Mail_and_news_settings There are news.wrap_long_lines and mail.wrap_long_lines, without any explanation. However in config editor there are mail.wrap_long_lines and plain_text.wrap_long_lines. I think the entry names about wrap and flow settings are confusing and should be renamed. I wonder under which circumstances does mail.wrap_long_lines take effect.
I just had the same problem. Setting mailnews.wraplength to 0 was the only thing that helped, even when using plaintext composition.
(In reply to Lu Wei from comment #3) > I think the entry names about wrap and flow settings are confusing and should be renamed. I never think "should", but think "it's better". Rename example. - Because mail.compose.wrap_to_window_width already exists, mail.wrap_long_lines => mail.compose.wrap_long_lines - mailnews.display.disable_format_flowed_support, mailnews.send_plaintext_flowed exist. mail.wrap_long_lines / news.wrap_long_lines => merge to mailnews.format_flowed.wrap_long_lines Because Mozilla implementation is very torelant with prefs name change, it can be easily done by following code change only, if new profile from scratch. - prefs.js entry name change in mailnews.js. - change of several code lines for reading/writing actual prefs entry in prefs.js file. However, for upward compatibility of prefs.js with older versions, "writing many code lines to migrate old prefs entry to new prefs entry" is forced if prefs name is changed. Downward compatibility is usually can not be guaranteed. Further, many documents in many Web sites, such as MDN documets, MozillaZine Knowledge Base article, have to be re-written by many volunteers. I believe "cost of rename==required workload/time of kind volunteers" is far greater than "gain by rename for pretty limited user's convenience or satisfaction". Even if it's better for many users, or even if any user can ask volunteers to implement code for his request any time in any bug at Bugzilla.mozilla.org, such change should be done upon big changes/re-writing or enhancements in mail composition feature or format-flowed support code.
Thanks for the explanation about naming difficulties. As a normal user, I find myself always get frustrated about those trifles. I am an engineer and I do not hesitate to read the fine manual, I like googling, I did carefully read those f=f and wrap documents, and thought that I have fully understood those things and will not get troubled into this again, but sadly, when today this thread revived, I find I have only vague concepts about them, and still confused about which pref setting is right! It's better the software be as intuitive as possible. As for me, I think I'd better not dive into these trifle issues and read the help again and again. I'll leave it until somebody complains about my wrapping again, and tell them just to endure it.