composing plain-text reply - no line break in quoted text

[jimspoon]

I have TB set to send plain-text replies. In the compose window, the text of the original message is quoted with the usual ">" and ">>" characters to indicate the reply level.

Unfortunately sometimes a paragraph of quoted text is sometimes displayed in the compose window as a single long line. I have to scroll the window horizontally to see the quoted text I want to reply to.

(1) Is there any way to have Thunderbird wrap the quoted text in the reply window so that I don't have to scroll the window to see it?

(2) Sometimes I will want to insert my reply in the middle of this long line of quoted text. So I will insert a line break at that point. Should I insert a > at the beginning of the line where the quoted text resumes, so that the quoted text will be display properly in my reply?

[Daifne]

Edit>Rewrap

Yes, insert the > at the beginning of the new paragraph if necessary. If you do the Rewrap first, this may not be necessary.

[rsx11m]

If this consistently occurs only with specific e-mails, ask the sender to switch off the "quoted-printable" encoding and use "8-bit" encoding instead (I cannot give you a more detailed instruction here as this will depend on what application they use). Some other clients produce e-mails with a single-line encoding of the first type, which causes Thunderbird to (correctly) connect all displayed lines to a single one in the reply.

[Anonymosity]

I found that wrapping of messages worked if I changed the @namespace lines of the messageBody.css file in the theme by putting comment markers around them (telling Tbird to ignore them). I noticed that problem with the theme Walnut for Thunderbird but not with Noia 2. Noia 2 had the @namespace already marked to be ignored.

[rsx11m]

Interesting, why would this depend on the theme used and a CSS entry in it...?
It seems to be a content issue, a theme defines the appearance.

[rsx11m]

Anonymosity, what exactly did you observe? I have now modified the "classic.jar" default theme for TB 2.0.0.9 with the

• // @namespace url("http://www.w3.org/1999/xhtml");

commented out in "messageBody.css", which didn't do anything with respect to either viewing such a message nor replying to it. I noticed though that if I reply to it to myself and then reply again to that message, the lines will be broken correctly in the replied-to reply (with or without the namespace definition).

I found the problem described in bug 344119, was has been resolved as a duplicate but summarizes the problem. In the original bug 196033, I found a comment with hints to overwrite the CSS settings in "messageBody.css" using the "userContent.css" file. Tried the following

Code: Select all

.moz-text-flowed {
   max-width: 80ch !important
}

.moz-text-plain {
   max-width: 80ch !important
}

.moz-text-html {
   max-width: 42em !important
}

which influenced the display but not the format of the quoted message during composition of the reply.

[rsx11m]

To add yet another brief comment to this thread: There appears to be an extension for exactly the case we want to solve here, found it in a comment in the bug report, but haven't tried it myself thus far - http://autorewrap.mozdev.org/

[Anonymosity]

Anonymosity, what exactly did you observe? I have now modified the "classic.jar" default theme for TB 2.0.0.9 with the

• // @namespace url("http://www.w3.org/1999/xhtml");

commented out in "messageBody.css", which didn't do anything with respect to either viewing such a message nor replying to it.

When commenting out a line or lines in a .css file, the way to do that is with /* content */. Here is the way Noia 2 does it:

Code: Select all

 /* XXX Breaks the HTML rules below (.moz-class stuff), at least on Linux.
   "html|.class" doesn't work.
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
@namespace html url("http://www.w3.org/1999/xhtml"); 
*/

I was seeing enormously long lines when reading messages unless the content-type was message:flowed (or something like that).

[rsx11m]

When commenting out a line or lines in a .css file, the way to do that is with /* content */.

Thanks, I've mixed that up with JavaScript then, which allows both forms. Anyway, using /*...*/ instead of //... doesn't make a difference with the default theme on Windows XP SP2.

I was seeing enormously long lines when reading messages unless the content-type was message:flowed (or something like that).

That was my point - the reading is fine with the default theme, even with the @namespace line kept in. The problem occurs when you try to reply to the message, ending up in endless lines.

The problem is that certain e-mail clients (discretely linked to in the extension web page) are incorrectly using "=" delimiters rather than "=20" delimiters at the end of each line in plain-text quoted-printable encoding with the format=flowed option set. So, it is one of those cases of somebody else screwing it up and Thunderbird having to deal with it. If this problem is "fixed" by always wrapping the lines in a specific way to make this encoding work for replies, it would break other things...

[Anonymosity]

In Options/Preferences > Composition > General, the setting for "wrap plain text messages" is set to 72 characters. That works for me when I compose messages.

[rsx11m]

... yes, except when you reply to a message in that specific format. The text you write is wrapped correctly, not so the quoted text of the original message (all in plain-text mode). You will need a message sent from a respective e-mail client in quoted-printable format in order to reproduce that effect, or modify a (correct) message you received accordingly. Did you check it on a message that shows the characteristics I pointed out two posts up?

[Anonymosity]

Lately, I have not noticed what content-type or exact code is used in the messages, but since I get messages composed on various email and news clients in various different formats and they all wrap properly, it would seem that I no longer have a problem.

[rsx11m]

I have prepared some examples to illustrate the difference in encoding and how they affect the reply format - remember that this affects plain-text replies only.

Code: Select all

Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

This is a message which is correctly=20
flowed, will span over the window width=20
when viewed, and break correctly into=20
lines when replied to.

This is how Thunderbird encodes messages when the quoted-printable box is checked in Tools > Options > Composition > General and 8-bit characters (e.g., with accents or umlauts) are used. Note the "format=flowed" attribute and the "=20" weak like breaks at the end of the first three lines, allowing the receiving client to rewrap the message when displaying. This example wraps to two lines in a reply with a 72-character wrap length.

Code: Select all

Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is a message which is incorrectly =
flowed, and will be in a single line =
when replied to even though it may be =
displaying correctly...

Example message as seen, e.g., with Microsoft and Lotus Notes e-mails: The "flowed" attribute is not set, and rather than having line breaks, they are using the "=" continuation marker. Thus, this is in fact a single line according to the standard, and will be presented in a reply like this. Interestingly, if the "format=flowed" attribute is added, it will break again into two line on a reply, which is the reason that the reply-to-a-reply works (Thunderbird will add the flowed attribute in its reply despite retaining the full line length).

Use View > Message Source to see those headings and the encoding. Hope that this clarifies the issue a bit more.

http://kb.mozillazine.org/Plain_text_e- ... wed_format