186732 - Add button to Wrap/Unwrap current message display

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Kalin Kozhuharov]

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!

Comment 1

[Jingyu Qiao]

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

Comment 2

[Devin Bayer]

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.

Comment 3

[Igor Velkov]

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.

Comment 4

[Kalin Kozhuharov]

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

Comment 5

[Igor Velkov]

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

Comment 6

[Max Alekseyev]

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

Comment 7

[Igor Velkov]

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.

Comment 8

[Paul Kramer]

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

Comment 9

[Robert Kaiser]

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

Comment 10

[Robert Kaiser]

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

Comment 11

[Robert Kaiser]

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

Comment 12

[Igor Velkov]

Feature request still active. at least my comment #7