Most mails I recieve - are (non-"format=flowed") plaintext - contain text that flowed when it had been composed - do not contain ascii-art However, some of them contain fixed lines, i.e. linebreaks matter, e.g. source code. I would like these mails to be displayed as if they were format=flowed. I.e. don't end the line on the screen, where it ends in the msg source, but continue the paragraph until an empty line. It is an IMO logical extension to variable width fonts and "wrap long lines". In other words, this feature is about "wrapping all lines other than empty ones". I consider this being more comfortable for reading, because I can adjust the display width as I like, not at exactly 80 chars ("wrap long lines" doesn't help, unless you adjust at exactly 40 chars). I want to add a hidden pref, default off, to switch this on. Default off, because it's only heuristic and is potentially destructive in the failure case. Hidden, because this feature and its consequences are hard to communicate to average users. Implementation: - Generally, output neither <br> nor <pre>. - Insert <p>, if an empty line is detected. - Address the "source-code problem" with a bit more heuristic: - If a line contains less than n chars (with n ~ 60), insert <br>, if the next line is empty. I am working on it right now.

I have this working in my tree. Will attach patch after more testing/finetuning.

> if the next line is empty. before each line until the next empty line.

Logic: Added a bit more heuristics. Now works (mostly) fine for bugzilla spam and supercite quotes (so, the example 3 screenshot is invalid). Patch: The majority of the new code is only executed, if the pref "mail.all_plaintext_flowed" is enabled. Also - removed old ifdefs - preallocate a reasonably sized string using |SetCapacity|, so it should run faster, if the pref is off. - fixed a leak in a failure case Rich, can you review, please? Design: In the long term, this functionality should be added to the generic TXT->HTML converter mozTXTToHTMLConv, but we'd have to use it as stream converter in libmime then, which is non-trival.

Need a bit more time. Sorry. Hacking in some support for ASCII-art detecting (need to do most of it anyway for this bug) - see bug 20195.

Moving out to M20, out of pity for poor Netscape :). Hope, it won't rott.

Tell me, why didn't I attach a patch? Or at least make a local backup? I tried to delete ~/.mozilla, but actually deleted ~/mozilla, the folder with all my changes :-(((. All lost. Hurray.

for mozTXTToHTMLConv

Changing personal priorities. Giving away most of my bugs :-( (reassigning to default owner). I will still track these bugs closely. If you need my input, feel free to ask me. New owner: Please do *not* close these bugs (as WONTFIX or whatever you may find) unless they are fixed. Rather, reassign to <nobody@mozilla.org>, if you don't want to work on them.

reassign to nobody@mozilla.org

mass move, v2. qa to me.

-> mailnews

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

Interesting. You can Message -> Edit as New, and then Edit -> Rewrap. Giving more visibility.

Joshua, this needs to be fixed in libmime, specifically mozTXTToHTMLConv, that's why it was Core.

eh, I mean mimetpla.cpp

Unless I'm mistaken, mimetpla.cpp != Networking,