718399 - Respect mailnews.wraplength whilst composing email

Status: UNCONFIRMED

(Thunderbird :: Message Compose Window, enhancement)

Description

[augustus_meyer]

When entering the message text for the body of an email in a line with more than 72 chars (default config value of Thunderbird: mailnews.wraplength), "silently" a <new_line> character is inserted into the text. 
"Silently" means, it is not displayed during composition of the messages.

It would be a good idea, to adhere to WYSIWYG and do an automatic wrap around
when exceeding the mailnews.wraplength number of characters in the input line.

Comment 1

[Hashem Masoud]

(In reply to augustus_meyer from comment #0)
Check if there is similarity to bug 657559.

Comment 2

[augustus_meyer]

I think, the effect, I decsribed, has nothing to do with window size.

One explanation would be, that the <new_line> after mailnews.wraplnegth-characters is inserted into the character stream AFTER entering complete text, so the wrap-around is not displayed.

The effect is very easy to reproduce:
Create a new mail, with >72 chars in body.
Examine email sent.

Comment 3

[rsx11m]

Are you composing in plain-text or HTML mode?

In plain-text mode, text wraps for me as desired while typing, though the location where it wraps may be off by one character in certain instances.

With HTML composition, I see what you describe (i.e., line is filled with characters until the right margin of the composition window is reached, then rewrapped when the HTML message is sent and down-converted to plain-text encoding).

Comment 4

[augustus_meyer]

You are right, in HTML only.

BTW: RSX11-M I (still) know like the contents of my pocket :-)

Comment 5

[rsx11m]

:-D

(In reply to Hashem Masoud from comment #1)
> Check if there is similarity to bug 657559.

That bug seems to be unrelated as it describes an issue of the window size not being correct for large attachment names. The bug here is of more general nature.

What is seen with HTML composition mode is probably the intended behavior, given that even once the HTML is wrapped to 72 characters per line, it still won't wrap like that when displayed (needs explicit <p> or <br> constructs).

But then, HTML isn't actually sent by default unless the message contains sufficient formatting (bug 136502 and related). Thus, one could argue that the message should wrap as it will be sent when no formatting is present, which may be confusing if an HTML part is sent in the end anyway which wouldn't show such wrapping.

For the plain-text part, the default is to send it with format=flowed set, thus allowing the receiving e-mail client to rewrap the message on its own (in which case mailnews.wraplength is meaningless for the interpretation. However, there are plenty of e-mail clients out there which ignore f=f and just show the message with "hard" line breaks and wrapped as encoded.

So, it's a mixed bag to figure out what may be the "right" thing to do here.

Comment 6

[augustus_meyer]

>is probably the intended behavior< :-)
Undeterministic software ? :-)

OK, you (almost) convinced me.

I agree somehow on your explanation of the "mixed bag". So, let it be as it is.

Thanx for your patience.

Comment 7

[rsx11m]

Blake, this is mainly a UX issue. On one hand it's not very intuitive to figure out during HTML composition what's going to be sent (especially if no HTML is sent) but I don't see any way how to improve that in a reasonable way.

I couldn't find a similar bug report pending, thus removing the "dupme" keyword.