User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 Here are some related bugs: Bug #109350 RFE: Add view -> no wrap of text to message view Bug #145895 not obvious how to turn off text wrapping Bug #173644 donot want to wrap plain text messages Bug #160468 Remove "Wrap plain text messages at ___ characters" pref UI In the URL you can see the "W" button on NoteTab. (http://www.notetab.com/ntp1.gif) Reproducible: Always Steps to Reproduce: Why a button? Well in wrap mode single click unwraps the message, on more click (or one single double-click) wraps it back again, thus effectively rewrapping it (what does now the View|Rewrap menu item, but it is "too deep"). When I was using Windoze, NoteTab Lite had such button, although rewrapping was not needed with plain text. I know this can be user implemented in any skin (may be I will try), but isn't it worth doing in the main trunk? Waiting for your comments!

*** Bug 173644 has been marked as a duplicate of this bug. ***

Is either having the whole message wrapped or unwrapped the best idea? I would primarily use a "temporary don't wrap" feature to paste patches and logs into an email message. Above and below the patch (or log) there would be explainatory text, signatures, etc. that should be wrapped. The way vim handles this is acceptable and better then the proposed method, but still not ideal. FYI: vim normally wraps new lines at 70 chars as they are being entered, but will not rewrap lines as they are edited. To paste a patch one enters a command ("set noautowrap"), then a command to resume normal wrapping ("set autowrap"). What about this idea: text which is not supposed to be wrapped should be pseudo marked-up with <pre></pre>. Even if the tags are not displayed (or sent) Mozilla could be aware internally that these lines should not be wrapped. A small problem I see with this is inserting HTML code with <pre>'s. But as long as the code is well-formed XML we could just ignore nested <pre>'s.

Maybe? there need 3 different bugs: 1. fast and simply to enable-disable line wrapping during mail composing - to be able to paste some logs, program sources, tables etc. It must be button in mail composition menu, or menu item. Not in preferences or settings menu! 2. fast and simply disable line wrapping for view one message, composed like in 1, or script-generated mail, etc. 3. to enable/disable text wrapping in mail viewing permanently I need 1 and 2, and dont need 3.

Have a look at mutt+vim, they do it properly.

I will pay $50 for enh as described in Comment #3 From Igor Velkov 2004-05-12.

*** Bug 183928 has been marked as a duplicate of this bug. ***

Ok, price increased. $100 for 2 enhancements: 1. button or menu item in compose new message for enabling|disabling auto-wrap new text. 2. button or menu item in main mail window (with folder list, mail in folder list, and message body), and in mail view window, to fast enable-disable auto wrap mail text. Usable for viewing program source codes, or logs. This offer will be active until end of january, 2005.

*** This bug has been confirmed by popular vote. ***

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Feature request still active. at least my comment #7