Currently "Rewrap" doesn't really do all that much (fixes quoting wrapping?) Much more useful would be if it could fix hard linebreaks also in the non-quoted portion of the text (similar to eClean, http://www.jd-software.com/eClean2000/). Basically, text with hard returns (whether quoted or not) should be converted to soft returns. "Rewrap" should follow a simple but powerful algorithm for removing hard returns at the end of lines: 1. Don't combine lines ending with punctuation (".", "-", ":", "?", "!") 2. Don't combine lines beginning with characters: "Subject:", "CC:", "To:" etc 3. Don't combine lines beginning with digits (1, 2, 3, etc) 4. Don't combine lines if separated by more than one hard return (paragraph). Text *before* rewrap: The days of reading messages that are full of line breaks and gibberish are over! This easy to use program makes reading clean e-mails as easy as pasting the message into eClean and watching all of the mess disappear. Download eClean and start reading clean, understandable e-mail messages today. Text *after* rewrap: The days of reading messages that are full of line breaks and gibberish are over! This easy to use program makes reading clean e-mails as easy as pasting the message into eClean and watching all of the mess disappear. Download eClean and start reading clean, understandable e-mail messages today.

Oops, the "Text *after* rewrap" should have been: The days of reading messages that are full of line breaks and gibberish are over! This easy to use program makes reading clean e-mails as easy as pasting the message into eClean and watching all of the mess disappear. Download eClean and start reading clean, understandable e-mail messages today.

There are risks in doing this. Your last comment shows that it comes out with strange line breaks. The third line is really too short. I don't consider this a good solution. Rewrap is by Akkana in Editor:Core, changing component. pi

Finally to Akkana. pi

RE comment #2: We don't know if the author of the above example intended "disappear." to be the end of a paragraph or not. However, it is the end of a sentence (".") that ends with a hard return. Statistically, this will happen very rarely for cases where the author hadn't intended a paragraph break (there are far more lines that end in a hard return that do *not* have a punctuation at the very end). Also, many authors separate paragraphs by only *one* hard return, so we don't want to turn their paragraphs into one huge paragraph. Therefore, it is more likely that these edge cases would be an intentional and wanted paragraph break. In the relatively rare occasion where a hard return was not desired, it is very easy to scan the document after "rewrap" and remove those hard returns manually. The effort is far less than "rewrapping" an entire document by hand. I use eClean a lot, and believe its algorithm is a highly useful tool. BTW, it would be great if "Rewrap" only rewrapped the selected text, if text is selected (if no text is selected, rewrap all text). New bug? Also, maybe selecting "Rewrap" should bring up a dialoge (another bug?): +- Rewrap options --------------------+ | | | (o) Rewrap entire message | <-- default | ( ) Rewrap only quoted portions | | ( ) Rewrap only non-quoted portions | | ( ) Rewrap selected text | <-- Selected if text had been selected. | | Grayed out if no text is selected. | [x] Remove quoting characters (">") | <-- Operates on portion selected above. | | Grayed out if 3rd option selected | [ Cancel ] [[ Rewrap ]] | +-------------------------------------+ This would be awesome for forwarding those jokes with a bazillion ">>>" in them.

> We don't know if the author of the above example intended "disappear." > to be the end of a paragraph or not. Yes, but the best guess is to say a paragraph ends with end empty line. Very often I see lusers using Outbreak Excess which have completely stupid line breaks. Sometimes in the middle of a sentence and sometimes (by chance) after a sentence. As your example shows, it looks poor to assume to much. If you really don't want to have this, mark the part to rewrap and apply then. > However, it is the end of a sentence (".") that ends with a hard > return. Statistically, this will happen very rarely for cases where > the author hadn't intended a paragraph break I see it all the time. > (there are far more lines > that end in a hard return that do *not* have a punctuation at the very > end). Also, many authors separate paragraphs by only *one* hard > return, It doesn't look as more than one paragraph before so it should not later. > I use eClean a lot, and believe its algorithm is a highly useful tool. I wrote this here in vim, it doesn't follow the rules, but produces nice results. > BTW, it would be great if "Rewrap" only rewrapped the selected text, > if text is selected (if no text is selected, rewrap all text). New > bug? WFM > Also, maybe selecting "Rewrap" should bring up a dialoge (another > bug?): That would make it more complicated to use. Suggesting WONTFIX. pi

I have very frequently seen (particularly from Word & Outlook users): This is a medium sized sentence. This is a medium sized sentence. This is a medium sized sentence.<p> This is a medium sized sentence. This is a medium sized sentence. This is a medium sized sentence. This is a medium sized sentence.<p> This is a medium sized sentence.<p> Therefore, it would be bad to turn it into this: This is a medium sized sentence. This is a medium sized sentence. This is a medium sized sentence. This is a medium sized sentence. This is a medium sized sentence. This is a medium sized sentence. This is a medium sized sentence. This is a medium sized sentence. We could get rid of the suggested dialoge, if: (A) only the selected text gets rewrapped, if text is selected (else *all* text) (B) We had another menu item for "Remove quoting characters". ... | Format | Options | Tools | ... +---------+-----------------+ | Select Address... | | Quote Message | | Rewrap | | Remove quoting characters | <-- add this feature :) |---------------------------| | ... | BTW. "Rewrap" should also get rid of extra spaces (only at end of lines?).

Actually, I do see you example differently all the time where line breaks happen basically this way: User types text in a brain dead reader (let's call it Outbreak Excess) and makes hard line breaks after say 100 characters. The reader is configured to do line breaks every 70 characters. This looks similar to your example, but punctuation is only occasionally at the end of the line. It happens, though, and is not intended as the end of the paragraph. But please note: (A) only the selected text gets rewrapped, if text is selected (else *all* text) already works. (B) We had another menu item for "Remove quoting characters". would be a new bug. pi

Well, we can't fix other broken programs (doesn't LookOut wrap at 70 on-screen if configured to send at 70? :-\ ), therefore people who intentionally use only one <RETURN> to create paragraphs should receive priority. Thus, a period (".") at the end of a line should be interpreted and a paragraph break. BTW, I just filed bug 173053 to handle "Remove quoting characters". Check it out.

I see your point, but it is way more common to have broken texts to fix than any other reason to rewrap. Anyways, rewrap belongs to Akkana. The arguments are layed out. She will have to make up her mind and decide. pi

cc'ing akkana

I'm having trouble following the thread of the discussion here. Several questions: First, people are asking here for rewrap to: > fix hard linebreaks also in the non-quoted portion of the text which means to me: in the part of the text that you yourself just typed. In the mail compose window, either text is quoted, meaning it is from someone else, or it is unquoted, meaning it is something you have typed into this compose window. Occasionally other cases show up, text pasted from {wide range of client types}. Then later, people justify this by talking about people who use Outlook and hit return at some inappropriate line length, which obviously doesn't apply to new text you yourself are typing into a mozilla compose window. Is it possible that this is asking for a rewrap in the message viewing window, not in the mail compose window? That would be quite a different thing and would have to go to a mail person, though I'd be happy to assist in using the rewrap/cite classes in this way (they were originally designed to be useful to clients outside the editor as well as within it). Next: our message viewing, html mail compose, and plaintext mail compose windows all wrap text for you (either to window width in the html and format=flowed cases, or to the wrap length in the plaintext non-flowed case. So long lines should display well. In the rewrap which is being asked for here, are people asking for text to be rewrapped now at the current wrap column setting, or for lines to be joined together so that they'll be wrapped by layout as appropriate in the given window, and wrapped by the serializer upon sending?

Akkana, I'll try to respond to your (good) questions: > fix hard linebreaks also in the non-quoted portion of the text Yes. This is useful for when user pastes text from other sources (another e-mail, webpage, etc.); also for forwarded messages where the forwarded text has poor line breaks (e.g., forwarded jokes). > asking for a rewrap in the message viewing window? No, this bug is requesting "Rewrap" in the compose window (but yours is a good idea for another bug). > asking for text to be rewrapped now at the current wrap column setting? Tough question. The short answer is "Yes" (I think). IMHO, in html and format=flowed "Rewrap" should create soft returns and let the window do the wrapping. For non-flowed cases, "Rewrap" should attempt to recreate what the text would look like if it had been typed directly with wrap column setting ON (hard returns at collumn x?). [OT] I have "wrap plain text msgs at 72 chars" set in prefs, but selecting new msg -> options/format/"plaintext only" still reflows in the compose window when i resize it. But a new msg in a NG (pref: don't compose HTML) wraps text at collumn x. Resizing the window has no effect on wrapping (nothing wraps). Hitting RETURN in the middle of a line reflows the following text (nice). So I am thoroughly confused about the whole "format=flowed vs. non-flowed" issue. Are those "hard returns" in NG msgs? Do they turn into hard returns at the recipient's end? Why does switching from HTML to "plaintext only" not yield the same (wrapping) behavior as a NG msg? :-\ [/OT]

Marking NEW then. Reporter, please try to state again your proposal based on the discussion. Please describe *exactly* what should happen in which situation. pi

Akkana, do you need a spec, as Boris requested, or are the descriptions in comment #0, comment #1, comment #6, and comment #12 sufficient? I think the idea is pretty clear. PS. This would allow me to remove one more icon from my taskbar (eClean). Woohoo.

This would definitely need a detailed spec (or a developer who has a spec in mind). Don't forget to address possible format=flowed issues, and specify how the function would work in each of: html, non-flowed plaintext, and flowed plaintext cases, copying/pasting from plaintext and various types of html constructs. Include lots of test cases covering the various combinations. (The different combination could be done separately, though, so if there's one specific combination that causes a lot of grief, that could be addressed without having to tackle the whole "Make rewrap do the right thing for all new text in all cases" project. I'm not sure why you removed the helpwanted keyword -- this still sounds like a big job, which I don't have cycles to take on right now (but would be happy to help someone else who wanted to contribute). Putting it back.

Another algorithm rule or two: 5. Don't combine lines beginning with bullet characters (- *) or what appear to be snip markers ([...], <snip>). 6. Treat lines with a higher quote level than that of the beginning of the paragraph as starting a new paragraph. As my home-made rewrapper http://smjg.port5.com/faqs/usenet/quotetidy.html does.

Re: comment 4 This would perhaps annoy people who like to be able to just select Rewrap and be done with it, without being interrupted by a dialog box. But your idea combined with that in comment 6 would be about right IMHO: | Edit | ... +------+--------------------+ | ... | | Rewrap | | Rewrap Quoted | | Rewrap Unquoted | | Remove Quoting Characters | | ... | +---------------------------+