Open Bug 40871 Opened 25 years ago Updated 6 years ago

[RFE] Ability to adjust the line length in outgoing plain text messages

Categories

(SeaMonkey :: MailNews: Composition, enhancement)

Product:
SeaMonkey
Component:
MailNews: Composition
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: John.planb, Unassigned)

Details

When writing a plain text the user should be able to adjust the line length that will be used. This came up in a recent thread on line lengths in n.p.m.mail-news, n.p.m.editor, where I said: > So, the options are: > 1) per message pref for line length > 2) global pref, applies to all open windows > 3) global pref, applies to all NEW windows > > If you do (1) then the global pref should be (3), if you don't do (1) > then the global pref should be (2). To which Akkana replied: > Fortunately, our backend supports all of these options. So > it's really just a UI choice. [...] Put me on the cc list -- > I'll be happy to help show the owner of the bug how to tell > the editor to change its line length. I'm putting the severity as "enhancement" but really feel it's a UI bug to not allow at least /some/ change on a per message basis.
reassigning to ducarroz. cc'ing rhp.
Assignee: putterman → ducarroz
I'll confirm this; I think it would be a good idea. It would be trivial to add it to the compose UI.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is this only an enhancement for mail? What about composer?
QA Contact: lchiang → fenella
Line length only applies to plaintext, and right now, plaintext composer is a debug-only feature (though personally I'd like to see us make it available).
Accepting
Status: NEW → ASSIGNED
Target Milestone: --- → M20
While looking searching for another bug, I came across this bug. I thought there was a global pref for setting the line length of plain text messages being composed. I see a pref labeled "Wrap plain text messages at [] characters" in the Message Composition tab. This sounds (to me) like what the user was requestions (option #3). Sorry if I'm wrong/out-of-place on this one.
Yes, that's it. It should also change the visible wrapping in the plaintext mail compose (but not in html mail compose). Why, is the editor not sending that pref to the output system in html mode? In plaintext mode? If the problem is in html mode, then I might know what the problem is: html mail compose, for some reason, saves its output as html, then later translates that to plaintext, and perhaps isn't checking the pref when it does the plaintext conversion. There's another bug somewhere saying that it shouldn't go through this double path, it should save straight to plaintext (which would solve the problem, since I'm pretty sure the editor sends the line length when saving as plaintext).
QA Contact: fenella → esther
Target Milestone: --- → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla1.0.1
The plain text output of Mozilla is actually: Content-Type: text/plain; charset=us-ascii; format=flowed The "format=flowed" is the problem. When MOZILLA or some other news or e-mail client see the format=flowed tag, it reformats the displayed text to fit the current width of the window instead of the width desired. Other e-mail clients see the text wrapped as the sender thought they were sending it. To be compatable with the expectations of the users, the format=flowed needs to be removed. The selection of FORMAT=FLOWED should be it's own selection box next to the plain text box. This will allow it to be set to the way that the users expect. In looking through the comp.os.vms newsgroup, only the posts from Mozilla use the format=flowed format.
This is a compose and send bug, not a problem with displaying what was received. Which means that whether the message is format=flowed or not is irrelevant.
Rereading the initial description, what you are asking for is some way to change the line wrap or margins for the message being composed on a per message basis. That is very handy when typing in replies where you want to emphasize something. Like an example paragraph wher you want the margins to be smaller. Disabling format flowed is RFE bug # 71110.
In my last update I meant bug # 86607 Sorry for the confusion.
Product: Browser → Seamonkey
Assignee: ducarroz → mail
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: esther
Target Milestone: mozilla1.0.1 → ---
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
Status: NEW → UNCONFIRMED
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
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
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
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
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
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 still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
Still a valid and useful enhancement. Even Netscape 4.80 had a small blue marker at the top to denote the right margin. We could make that draggable, or have a thin vertical draggable bar overlaying the content etc. pp.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: EXPIRED → ---
Assignee: mail → nobody
Status: REOPENED → NEW
Component: MailNews: Message Display → MailNews: Composition
QA Contact: mailnews-composition
As far as I remember, this was implemented 1-2 years ago in another bug. Closing WFM.
Status: NEW → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → WORKSFORME
pref "mailnews.wraplength" <http://hg.mozilla.org/comm-central/rev/1211fc933b33> Bug 277043 Wrap column ignored for messages composed as HTML, sent as Plain
Sorry, but that's not the point, we do have the line limit *pref* for a long time. This missing part is changing that dynamically in the composer UI.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
> This missing part is changing that dynamically in the composer UI. I think that's a WONTFIX. I cannot see a valid and *common* reason to want to change this for a single message. Maybe for a paragraph, very rarely, but for that it's easier and more intuitive to do it manually. Since the bug was filed, a lot of bugs around this were fixed. The pref "wraplength" now actually works. It now applies to messages written in HTML editor and sent as plaintext. It also applies already in the plaintext composer while typing. For the cases where you need it to change it for one message, you can either wrap manually or change the pref temporarily. Suggest WONTFIX. Need to limit the UI clutter.
You need to log in before you can comment on or make changes to this bug.