Closed Bug 145900 Opened 22 years ago Closed 22 years ago

no way to virtually wordwrap message composition at window size

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED DUPLICATE of bug 20240

People

(Reporter: u32858, Assigned: kinmoz)

References

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
BuildID:    2002051013

no way to wordwrap message composition at window size, message display has this
option

Reproducible: Always
Steps to Reproduce:
1.check preferences -> mail & news
2.
3.

Actual Results:  can not wrap at window size for composition, message display can

Expected Results:  should have same feature as message display IMO
I don't understand what exactly your problem is.

Do you want that long lines (e.g., in quotes) are virtually wrapped (there
already is a bug for this).

Or do you want that messages are actually sent wrapped at window width?

pi
reassign to editor
Assignee: ducarroz → kin
Component: Composition → Editor: Core
Keywords: mailtrack
Product: MailNews → Browser
QA Contact: esther → sujay
> ------- Additional Comments From bugzilla@piology.org
> I don't understand what exactly your problem is.
> 
> Do you want that long lines (e.g., in quotes) are virtually wrapped (there
> already is a bug for this).

Hi,
I meant that they are virtually wrapped, Like there is an option in the
"Display" section of preferences to wrap at window size, so i think it would be
useful for compostion as well.

shall i resolve?

> Or do you want that messages are actually sent wrapped at window width?

I have submitted another bug that it would be usefull to have a way to specify
that composition would not be converted  to 72 chars per line when sending as well.

JG


I cannot find the dupe, certainly Akkana knows -> CC.

pi
Whiteboard: DUPEME
*** Bug 146100 has been marked as a duplicate of this bug. ***
I just found bug 20240 which is marked as INVALID. This is not the bug I have in
mind, though.

pi
I'm not aware of any bug of which this is a dup, or indeed of anyone ever asking
specifically for this (you specifically want to see your reply displayed
differently from the way it's going to be sent?)

The partial patch checked in for bug 134439 included a patch to make the
composer window non-wysiwyg like this as part of some other changes, only when a
pref was set, but it looks like there's no way to reconcile the output changes
with the expectations of format=flowed space stuffing, so I'll probably end up
backing out the patch that was checked in.  If you really want to see that, you
might want to go argue in that bug that I shouldn't back out that part of the patch.

It would help to know what mail people want to do about this issue.
>I'm not aware of any bug of which this is a dup, or indeed of anyone ever asking
>specifically for this

We had this discussion somewhere in one of the wrapping bugs. I spent another
hour without finding it. Well, for the time being, this is a reasonable thing to
ask -> NEW.

>(you specifically want to see your reply displayed
>differently from the way it's going to be sent?)

Let me try to rephrase the suggestion: Assume you receive e-mail with a line
which does not fit the screen. It is hence virtually wrapped so you can
completely read it. Upon answering this lines stays one line (which is correct
behavior:-) but parts of the line are displayed outside the screen, so you have
to scroll. The suggestion wants to also virtually wrap the long quoted line so
it is completely readable without scrolling.

>The partial patch checked in for bug 134439 included a patch to make the

I don't think this here is a WYSIWYG issue, but WYSIWYG is crucial, of course.

pi
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think there should be a way to compose a messge using the full screen size,
then  it can be sent however the user has configured it.  It is independent of
send format.

Perhaps I would configure it to not wrap any long lines, useful for including in
other documents etc.

Composition has options that display of messages does not have and vice versa.

JG
So basically this is just asking for a style on the quoted text so that it would
display as "pre wrap" rather than "pre"?

That would be easy to do -- I could pretty easily whip up a patch to do that. 
It seems like a reasonable request (in fact, it might be nice to have a View
menu item to toggle that).

Or is this also asking for the new (non-quoted) text to be wrapped at window
width rather than send width?  That's a bigger and more radical change.  If
that's what's being asked for, would it always have to do this, or only if mail
wrap column is set to 0?  I'd be hesitant to implement anything like that when
there was also a wrap column, for fear that (1) the author would see something
significantly different from what was being sent and (2) that might lead to
miswrapped (long-short-long-short) mail like we used to see from 4.x from users
who hit return at the end of every line.
Hello,

I'm not sure if i understand your comment fully,

> ------- Additional Comments From akkana@netscape.com  2002-05-23 17:14 -------
> So basically this is just asking for a style on the quoted text so that it would
> display as "pre wrap" rather than "pre"?

Hmm, i was thinking that i can make the window huge and type text, then click
send and it will be formated how that is setup.  There could be 2 options,
wordwrap at 72chars and send at 72chars (current) and compose at full window
size and send at how ever the send format was configured, wrap at 72chars or
other etc.


> That would be easy to do -- I could pretty easily whip up a patch to do that. 
> It seems like a reasonable request (in fact, it might be nice to have a View
> menu item to toggle that).

good!
 
> Or is this also asking for the new (non-quoted) text to be wrapped at window
> width rather than send width?  

I was just thinking compose mode, but send mode would also be useful, i think
allowing maximium customisation for compose/send formats is useful

> That's a bigger and more radical change.  If
> that's what's being asked for, would it always have to do this, or only if 
> mail wrap column is set to 0?

the later, if mail wrap was set to 0 then it could be send as long lines etc


> I'd be hesitant to implement anything like that when
> there was also a wrap column, for fear that (1) the author would see something
> significantly different from what was being sent and (2) that might lead to
> miswrapped (long-short-long-short) mail like we used to see from 4.x from users
> who hit return at the end of every line.


posibily, but it would depend on the preferences display format as well.

It seems more complicated to explain my idea than I orgionally considered

JG 

Akkana:

> So basically this is just asking for a style on the quoted text so that
> it would display as "pre wrap" rather than "pre"?
>
> That would be easy to do -- I could pretty easily whip up a patch to do that.
> It seems like a reasonable request (in fact, it might be nice to have a View
> menu item to toggle that).

Sounds good to me. That will do it. For any real wrapping we have other bugs.

pi
I would agree that this is an issue. Right now it is limited to the General
Preferences/Mail & Newsgroups/Composition/Composing Messages Wrap plain text
messages at __characters.

This option is confusing, because it works differently than old Netscape
iterations (ie. 4.8 and lower versions). In old Netscapes, the word wrap
features was "wrap outgoing plain text messages at: ____ characters". Mozilla
appears to NEVER wrap outgoing messages, which is good for me, but
UNFORTUNATELY, I am forced to enter a fixed width to VIEW my message
compositions now, which is less flexible then the old versions of Netscape,
which wrapped message composition text to the window size.
I am sorry to be redundant and long winded, but after reading this full thread I
see that this issue seems to be confusing everyone who reads the thread. Since I
am a user who sees the VERY IMPORTANT need for this feature, I thought I should
chime in.

Here is the issue. When I am composing a message, the width of the text is
limited to the width that is specified by the user in the "General
Preferences/Mail & Newsgroups/Composition/Composing Messages Wrap plain text
messages at __characters." This seems completely unnecessary and
counter-intuitive to me, and actually a nuiscance.

It would be EXTREMELY useful to not be limited to any specified width, and for
it to just wrap to the current screen size. This should probably be the default
option in the Preferences, IMO. I don't see ANY advantage to wrapping the
composed text to a certain width, personally. This is a new feature uncommon to
ANY other mail composition tool I have ever used. That is not to say that you
necessarily need to delete the current feature, but DEFINITELY, a new feature
needs to be added that allows the text to wrap to the window's current size.

I am not requesting that any linebreaks be added (either by the user or the
application) on send or recieve. But rather that the application just wrap the
text that you are typing and automatically wrap not to any given character width
but instead to the window's current width (which obviously could be resized at
anytime and the text would reflow correctly since no line breaks were ever added).

If you still don't understand what I am on about, do this: Go to "General
Preferences/Mail & Newsgroups/Composition/Composing Messages Wrap plain text
messages at __characters." and enter a very large number like 3000. Then create
a new text message and type a very long line of text. As you reach the right
hand side of the screen you will see that the text starts to scroll to the
right. Of course this is not a bug, we specified 3000 character length, but I
ask you: Why do I need to specify a length at all? Why not have the feature that
automatically wraps according to the current message composition window? This is
how EVERY other  mail app works, why not Mozilla? Does the feature request make
sense now?
My only response is that, from Netscape 6 to Mozilla 1.2.1, I have yet to find
the wrapping behavior useful at all.  When wrapping is turned on, it wraps
displayed text at a fixed width, but does not actually wrap it when sending,
though it apparently does wrap the text at a fixed width if it is in the Unsent
Messages folder and you do "Edit as New".

Ideal behavior:
  Allow the choice of no wrap or fixed wrap when sending.
  Allow the choice of no wrap, same-as-sent wrap, or window-size wrap when typing.
  Do not wrap sent text until actually sending.

At the least, restore the Netscape 4 behavior.
John, you forgot to CC yourself -> CC

I don't understand, what you do. If you turn wrapping on, it does that. Do you
use HTML or plain text editor? Do you use format flowed?

pi
I don't know what format-flowed is, so take the following in light of that.

I use plain text.  If I turn wrapping on, the screen display of the message as I
am typing it wraps, but the actual message sent is not wrapped.  I cannot
reproduce the old Netscape 4 behavior of having the actual sent message wrapped,
which is, as far as I'm concerned, a Very, Very Bad Omission.  Right now, the
_only_ word-wrap feature displays a fixed width while typing, but does not wrap
while sending, which, as the original reporter observes, doesn't do much good
any which way you look at it.  If word-wrap is only to affect the compose
screen, it should wrap at the window edge, not at a fixed width.

The present choices are:

A. Do not wrap anything.

B. Soft-wrap the compose display at a fixed width.

They should be:

(A.) Do not wrap anything.

C. Soft-wrap the compose display at the window edge.  (Allows unwrapped text to
be sent without inconvenient horizontal scrolling.)

D. Soft-wrap the compose display at a fixed width, and hard-wrap the actual
message (when it is sent) at the same fixed width.  (Automatically provides
wrapping, and shows the message WYSIWYG.)

E. Soft-wrap the compose display at the window edge, and hard-wrap the actual
message (when it is sent) at a fixed width.  (Automatically provides wrapping,
and automatically provides a convenent display, but not WYSIWYG.)

F. Soft-wrap the compose display at the window edge, and hard-wrap the actual
message when it is sent at that same width.  (Automatically provides wrapping,
with user eyeball control of where it will happen.  Useful if wrapping is to be
done at varying widths for different messages, since it's easier to resize the
compose window than to go into Preferences.)

Options A and D were on Netscape 4.  Option D is what I personally want.  Option
C is what the original reporter wants.  I don't know whether anyone actually
wants options E and F, but they at least make sense.  The current option B is
just silly, and it is confusing to people converting from Netscape 4, because it
is presented to users in the same way that Netscape 4 presented option D.
Hi jwkenne@attglobal.net,

As I filed this bug, i feel i should comment :)

You made some good ideas, something does _need_ to be done about this, I am sure
it should be ranked higher than minor, a feature is not present, "normal"
priority at the least.

Regarding sending wrapped format, the only way I have found is to save as a
draft, then re-open (as the draft format is broken too, it stores word-wrapping,
when it should not).

Regards

JG
> Regarding sending wrapped format, the only way I have found is to save as a
> draft, then re-open (as the draft format is broken too, it stores word-wrapping,
> when it should not).

Anyone know if this has been filed as another bug? I can't find it, but then the
search engine never finds many of the bugs from keyword search.

JG
I don't understand why I said this is not a dupe of bug 20240. Now I believe it is.

John, if you send yourself such a mail which has those long lines. Receive the
mail an press CTRL-u. Look at the Content-Type in the header. Does it say
format=flowed? Look further down to the body, how long are the lines?

pi
Summary: no way to wordwrap message composition at window size → no way to virtually wordwrap message composition at window size
OK, the CTRL-U and the reference to 20240 were the vital clues I needed.  I've
tracked down RFC 2646, and now understand what's been happening, and how to get
the results I want.

I can't help but think that other people coming to Netscape 6/7 and Mozilla are
going to be as confused as I was.  A hint or two in Help and a pseudo-bug filed
here could help.

One final question:  Earlier, I was asked "Do you use format flowed?"  Do I have
a choice?  (I'm not saying that I want to change, but I don't see an option, and
searching Help provided nothing on the subject.)
http://www.hmetzger.de/etips6.html#32

Checking again, I do mark this as a dupe.

pi

*** This bug has been marked as a duplicate of 20240 ***
Status: NEW → RESOLVED
Closed: 22 years ago
OS: Linux → All
Hardware: PC → All
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
Incidentally, for people who are bugged at seeing the wrap when typing in the
message window, this pref:
user_pref("mail.compose.wrap_to_window_width",   true);
makes the compose window wrap to the window width rather than the width at which
it will be wrapped when sent.  (And it is indeed wrapped, even when it's sent as
format=flowed; I just verified that.  The only difference is that some wrapped
lines have spaces at the end of the line to indicate "soft linebreaks", so that
mailers such as mozilla which understand format=flowed can then unwrap those
lines and rewrap them to a different line length.  Check the actual message
source and you'll see that it's wrapped just where the compose window said it
would be.)

Anyway, I don't understand why someone would want to see the message unwrapped
rather than see it as it will actually be sent, but if anyone really wants this,
that's the pref to set.  It's not officially supported; no guarantees that it
will work forever.

Re JG's question (comment 19), I believe there may be a bug somewhere about
format=flowed lines not being preserved correctly when being read in from the
Drafts folder, but I don't have a bug number.
You need to log in before you can comment on or make changes to this bug.