Open Bug 196033 Opened 21 years ago Updated 2 years ago

Automatically wrap quotes in replies/followups (optional?)

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

People

(Reporter: 3.14, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

This is a typical mail with long lines
2.16 KB, message/rfc822
Details
This is how the previous mail is displayed
46.08 KB, image/png
Details 
Several bug reports complain that long lines are quoted as long lines (which is
correct, but nonetheless). Basically they are all dupes of bug 20240. As a
spin-off I file this bug to deal with that wish.

It was suggested to have an *option* to not only wrap new text, but also quotes.
Fine, if people want to use it. Let me cite myself from bug 192730 about the
risk of doing so, but if it is only an option, that seems OK:

"Wrap plain text message at" by desing does not apply to quotes. Why is this?
You see it for people using braindead readers like Outbreak Excess. They also
wrap quoted lines which results in something like this:

> This is the beginning of a quoted line longer than
the
> column you chose in "Wrap plain text message at" in
the
> preferences.

Even if you would add quote symbols you would end up with that pattern. To avoid
it we would need to automatically apply (and you can already do it manually if
you wish) edit/rewrap. But there are messages where the line folding is
significant. To name a few:

- code listings
- test "tables"
- ASCII art
- lyrics
- situation where someone underlined a word
                          ~~~~~~~~~~
- anything with *text highlighting* (if "highligthing" wraps
  to the next line it won't work anymore)

So doing this automatically would create a dataloss (the formatting contains
significant information).

If you want to do it anyways, there must be an option to turn it off to avoid
those proplems.

So the idea is to have an option "Also apply word-wrap to quotes".

pi
The message viewer does wrap. The quote should wrap just the same. I don't see a
need for an option. in the rare case (ascii-art etc.) where we are wrong and you
want to keep the quote nevertheless correctly, you can manually delete the
linebreaks.

It's a bug IMO, because the current behaviour is not what users expect in the
common real-world case (communication with MSOE etc.).
Severity: enhancement → normal
Summary: Add option to automatically wrap quotes in replys/followups → Automatically wrap quotes in replys/followups (optional?)
> The message viewer does wrap.

It only virtually wraps, i.e. to window width. This is of course, what quoted
long lines will look like on receiving. To also virtually wrap when composing we
have already a bug which I don't find right now:-(

> The quote should wrap just
> the same. I don't see a need for an option. in the rare
> case (ascii-art etc.) where we are wrong and you want to
> keep the quote nevertheless correctly, you can manually
> delete the linebreaks.

In my personal experience those case (and it is not only ASCII art, but often
code oder underlining!) are pretty regular. Forcing the user to manually fix
this makes Mozilla very hard to use, especially for long texts.

It is also a problem with user expectation. People using Netscape sind 3 or 4
are used to that behavior which would now change dramatically. Speaking for
myself I would stop using Mozilla right away if we introduced the bug to remove
the formatting information.

Actually, bug 136977 is the same, but this here already has more information, so
I'll dupe that bug here and not vice versa.

Also CCing Akkana who is in charge of rewrap.

pi
*** Bug 136977 has been marked as a duplicate of this bug. ***
I don't think that quotes should look like the display of that message.

pi
IMO, quoted lines should NOT be wrapped.  Mozilla should prefix the lines with
"> " and that's it.

The reason why I don't think that wrapping should be done, is that I assume that
the user had a reason to send the mail the way he send it.  And Mozilla cannot
guess what the reason was to decide if wrapping is appropriate or not - hence it
shouldn't do something automatically.  THe only "thing" which can decide if a
mail should be re-wrapped is the user - and he can manually select Rewrap if he
thinks it's appropriate.
I guess we have to distinguish (at least) three cases:
1. 'regular' plain text
2. format=flowed plain text
3. HTML

ad 1:
The regular plain text editor should not autowrap quotes.
Long lines are long lines are long lines are long lines.
If the user wishes rewrapping, he can do so via edit->rewrap.
BTW: quoting quoted text underlined via '---^' etc. *is* *already* *broken*
because of quote character mangling:
-------snip--------
> bla bla bla
      ---
-------snip--------
becomes:
-------snip--------
>> bla bla bla
>       ---
-------snip--------

ad 2:
Plain text in f=f knows where to break lines. If there're long lines, there're
long lines. Composer should not rewrap these automatically.

ad 3:
I don't know, I don't use it. ;-)
Blocks: rewrap
Comment #6 says:
> and he can manually select Rewrap if he
> thinks it's appropriate.

But Rewrap does not work correctly for this problem.
Rewrap removes important line breaks as well as wrapping long lines.
Comment #8 says:

> But Rewrap does not work correctly for this problem.
> Rewrap removes important line breaks as well as wrapping long lines.

Yes, that's true - but an automatic rewrap would cause the same problems,
wouldn't it?
This may be part of this problem.  In moz 1.3 (win), I find that, on email
replies, when I first hit reply, it wraps nicely to about 75 or 77 chars
(quoted) REGARDLESS of the value of the preference (Mail & Newsgroups |
Composition | Wrap plain text messages at __ characters).

Then, if I do an Edit | Rewrap, it rewraps nicely to the value in that setting.

Why doesn't it automatically wrap to that preference value the first time? 
There should be no need to rewrap.   Please fix that aspect.  If you have a
setting for the wrap column, it should be followed without the extra step. 
Jeff,

please read the previous comments before writing a new one. As explained in
detail, automatic rewrap causes dataloss.

pi
Would it help the problem of rewrap messing up a message if there were 
a "rewrap-selected" command in addition to the current rewrap-(all)?  That way 
a user could selectively rewrap parts of a message if other parts don't work 
correctly in rewrap.  Pegasus mail has this and it's handy, particularly as 
it's on a keystroke shortcut (Ctrl-J).
Rewrap selected works already, but is pretty buggy. Anything you do manually is OK.

pi
*** Bug 217616 has been marked as a duplicate of this bug. ***
*** Bug 206116 has been marked as a duplicate of this bug. ***
*** Bug 217731 has been marked as a duplicate of this bug. ***
See also bug 208128.
> It was suggested to have an *option* to not only wrap new text, 
> but also quotes.
If you cared to hear my opinion, I would say that not wrapping quotes with long
lines sucks beyond measure. If you didn't notice, there are people out there
actually using their text editor as intended: hit the return key for a new
_paragraph_, not for a new line. And there are mailers out there which accept
this behaviour. The most prominent example in Germany is web.de, which does
_not_ enforce wrapped long lines. As I said, it sucks beyond measure to have to
break lines manually in a reply, especially after having seen the mail in a such
beautiful layout, actually using the entire monitor width. 

So, could the long quotes be wrapped to rendering window width? Can I somehow do
this now, and easier than my actual procedure ("Edit as new" -> Send to self ->
Reply)?

Kurt
I just wanted to file a bug about the wrong wrapping of text and the Rewrap
function when I came across this bug. I think what I have to say fits in here,
feel free to tell me to file a new bug if that is not the case.

I often get Mail from people which break the formatting like this:

---
>> This is the long line of text they quote from my original
> message
>> another line
> like this
Their reply
---

Which obviously messes up any coloring or searching for relevant quotes. Also
when I want to leave part of what they quoted from my message in my reply to
their message I have to rewrap everything manually. Also if I want to quote from
the middle of a line to the end of a paragraph I have to rewrap everything by hand.

I don't suggest any automatic way of rewrapping (not even something like the
rewrap menu entry) because that mostly messes everything up.

Lets assume I want to start my quote at the middle of a line. I delete
everything from the beginning of the line to where I want to begin my quote (new
sentence begins or whatever) The first line of the quote is now obviously too
short while all the others lines to the end of the paragraph are ok.

>> Short line
>> rest of the sentence to the end of the paragraph

You can now just hit delete at the end of ">> Short line" to make ">> rest of
..." part of that line. This is what you get:

>> Short line >> rest of the sentence to the end of
the paragraph

This is all one long line internally but shown wrapped at the 80 char barrier
(after 'of' in this example)

You can then manually delete the ">>" from within the sentence. If you then go
to the end of the first line (after the 'the' which will come to the first line
if you delete the '>> ') and hit 'enter' the line is broken up into two lines
which both begin with ">>". This i what you get:

>> Short line rest of the sentence to the end of the
>> paragraph

Oh and don't suggest to use the rewrap function from the menu. I tried that
after I found it.
Alex G: check out bug 148673, which addresses the specific issue of the broken 
quoting.  Note that the breakage in that case is not Mozilla's fault, it's the 
fault of whatever mail client your correspondent is using -- most likely Outlook 
Express.

As for the case of a short line/long line, Rewrap is *supposed* to handle cases 
like that, but it does have a couple of bugs; bug 187997 in particular makes 
your case difficult to fix.  Vote for that one, please!

I didn't understand this:
> >> Short line >> rest of the sentence to the end of
> the paragraph
>
> This is all one long line internally but shown wrapped at the 80 char barrier
> (after 'of' in this example)

Why are you showing that wrapped?  Mozilla doesn't wrap quotes; that's the point 
of this bug!
(In reply to comment #20)
> Note that the breakage in that case is not Mozilla's fault, it's the 
> fault of whatever mail client your correspondent is using -- most likely Outlook 
> Express.

Yes I know, I just want a good way to fix such broken messages when I need to
reply to such a message with more than one level of quoting. As is said in that
other bug an automatic rewrapping function may have difficulties with it. For
that case I wanted to suggest a new way of handling like it is done in KMail for
example.

> As for the case of a short line/long line, Rewrap is *supposed* to handle cases 
> like that, but it does have a couple of bugs; bug 187997 in particular makes 
> your case difficult to fix.  Vote for that one, please!

Ok seems to be in the same category as my wish. Whats also awkward in mozilla is
the handling of quote characters inserted. If I insert a '>' at the beginning of
a line the text stays black, when I rewrap, the text is blue so mozilla
recognizes it as quoted text.

> I didn't understand this:
> > >> Short line >> rest of the sentence to the end of
> > the paragraph
> Why are you showing that wrapped?  Mozilla doesn't wrap quotes; that's the point 
> of this bug!

Because this is what's supposed to happen. I hit delete after 'Short line'. If
there was a working auto rewrapper it would of course remove the '>> ' by itself
and add a '>> ' before 'the paragraph'. What I suggested was handling for the
case when an auto wrapper is out of question because of difficulties to
distinguish quoted and non quoted text. I thought that was why there is no auto
wrapper but the manual rewrap menu entry.

But well if this is just an error in the rewrap function I can live with it.
(In reply to comment #21)
> Whats also awkward in mozilla is the handling of quote characters inserted.
> If I insert a '>' at the beginning of a line the text stays black, when I
> rewrap, the text is blue so mozilla recognizes it as quoted text.

Bug 161968.
*** Bug 244428 has been marked as a duplicate of this bug. ***
Summary: Automatically wrap quotes in replys/followups (optional?) → Automatically wrap quotes in replies/followups (optional?)
*** Bug 257112 has been marked as a duplicate of this bug. ***
*** Bug 252868 has been marked as a duplicate of this bug. ***
A new Autowrap-extension has been developed. Works in Thunderbird 0.8. See:
http://autorewrap.mozdev.org/
*** Bug 261023 has been marked as a duplicate of this bug. ***
I think if the compose window wrapped long lines as the viewer does it (in a
virtual manner, as someone has said), then this would probably satisfy everybody
because all we care about is being able to read text without having to scroll
horisontally. Text need not be modified, just the view.
(In reply to comment #26)
> A new Autowrap-extension has been developed. Works in Thunderbird 0.8. See:
> http://autorewrap.mozdev.org/

Quoting from that site: "When you reply to some emails, the quoted reply appears
on one very long line. It's usually caused by someone using a lame email program
... that doesn't correctly wrap outgoing email messages; they just send a
single, long line of text for each paragraph."

In my opinion, it is Mozilla that is broken (or not completed yet). Text editors
have done what the "lame" email program does for ages: new line character is
used only for new paragraphs, and text width is controled by the viewer logic of
the editor. This way one can have text spread all over the screen or fit in a
two inch wide column. Wrapping that is done by the viewer in Mozilla should be
incorporated into the Composer, and no lines in outgoing mail should be
automatically terminated at a fixed position.
*** Bug 238114 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
*** Bug 273061 has been marked as a duplicate of this bug. ***
*** Bug 278955 has been marked as a duplicate of this bug. ***
*** Bug 283728 has been marked as a duplicate of this bug. ***
Here's another aspect of this problem.  Please advise if this should be a
separate bug.

Copy a paragraph of text from a web page and then "paste as quotation".
Result:  One big long line. 
Rewrap.
Result:  Lines that are still too long and do not appear quoted.
Do lots of editing work.  

Sheesh.  Mozilla makes these basic tasks WAY too much work.

In reply to comment 6:
>  I assume that the user had a reason to send the mail the way he send it. 

For many users, the only reason they send lines so wide is that they 
usually operate ALL their windows in full-screen mode.  They never see the
contents of more than one window at a time, and it always occupies the 
whole screen.  They make something that looks good to them and send it.
So, the people who view text in normal page-width windows see crap.

I consider that behavior rude.  As someone REPLYING to such a message, 
I do not wish to preserve the rude formatting of the orignal.  I wish to 
produce a reply that others will not also have to reformat.  I indicate
that to my email client by specifying the wrapping width (e.g. 76 columns).

How sad that my email client ignores that, and makes me do much work 
routinely (many times every day) to compensate for its refusal to comply
with my preference.
First of all, if there's a setting that tells the application to behave in a
certain manner then, as a user, I also expect it to do so. In other words, if I
tell Mozilla to wrap messages at a certain width then it should do so, and not
just the text that I wrote. If I wanted separate treatment of quoted text I
would go look for the "Do not wrap quoted text"-setting.

Second, it has been said that the problem is that the quotes are to long so that
one have to scroll to see the whole quote while typing the reply. A suggested
solution to this was to use "virtual wrapping". That is not a solution, it just
hides the problem. Worse, it leaves the problem to the person replying to your
mail who might want to include what you quoted in his reply.

Third, quoting from RFC2822:
There are two limits that this standard places on the number of characters in a
line. Each line of characters MUST be no more than 998 characters, and SHOULD be
no more than 78 characters, excluding the CRLF.

The limit of 78 characters is a very practical one, even if its reason isn't
something that Mozilla-users need to worry about. But fact is that many people
today still uses mail-readers which can not display more than 80 charactes per
row. Besides, research shows that lines long than that are harder to read (check
yourself, there are few novels out there with more charactes per line).

Yes I know the third argument is not really relevant to the question as to
whether to wrap quotes or not, but I think that it adds to why long lines are
bad and should not just be "virtually wrapped".


As for quotes that lose important information when wrapping (such as code etc),
how about this. Wrap the quotes, and if the user does not like it he/she can, as
the first thing he/she does, undo the wrap. This is the same effect as if using
Rewrap the first thing you do, except that you don't have to rewrap each mail
manually when replying.
*** Bug 327233 has been marked as a duplicate of this bug. ***
*** Bug 302653 has been marked as a duplicate of this bug. ***
*** Bug 344119 has been marked as a duplicate of this bug. ***
*** Bug 359789 has been marked as a duplicate of this bug. ***
Assignee: ducarroz → nobody
QA Contact: esther → composition
To recap one of the points made in duplicates: the wrap/nowrap issue applies equally (and in the preformatted text cases perhaps more so) to simple Paste as to Paste As Quotation. Currently the latter has one behaviour (along with Quote Message and Forward As > Inline) and the former has another.

One possibility that was suggested is a preference to turn on/off wrapping for all of the above. Another possibility, if it is felt that the current behaviour is the best default, would be two (or more) such preferences (e.g. one applying just to Paste and one applying to the others). Either way, users could then choose always to wrap or never to wrap. Not all of the preferences would necessarily need UI.
Just as a perspective matter -- I used to routinely use Mac Outlook Express (b. 1995-d. 2000) and it had automatic rewrap during compose/reply. The quoted text was forcibly hard-wrapped to the same soft-wrap limit (78 chars?) as text you wrote, and presumably hard-wrapped on transmit. I never had any complaints about this.

Thunderbird fails miserably to deal with a variety of MUAs such as Microsoft Outlook and Yandex.ru Webmail that don't hard-wrap -- the text is stated to be text/plain but fails to get wrapped. There is nothing much I can do to force the whole world to generate decent mail, but you should still "be liberal in what you accept, and conservative in what you send." The other software is plainly at fault but Thunderbird needs to cope here.

In Thunderbird, each paragraph of these mails goes way off the side of the window; they would be off the side of 30" displays too. How can I possibly reply to that?

Outlook Express on the Mac (apparently years ahead of its time) copes fine, but Thunderbird does not. For example, Outlook won't quote with ">" (or so I am told) so one correspondent of mine encloses each snippet of my text in double quotes and starts her reply on the next line. Mac OE considers these two lines t be separate paragraphs and wraps each indivually, but Thunderbird -- unware that the long lines suggest separate paragraphs -- merges them all together and I can't see who wrote what any more. (I must suggest she leave blank lines!)

Another correspondent uses hyphens to form bulleted lists, and Thunderbird wraps all of those into the same paragraph, making the list now useless to follow. Individual paragraphs themselves won't wrap properly, but that's bug #187997.

I do understand that there are significant data loss concerns here but this is NOT Thunderbird's concern. The e-mail standard is flawed and it's sadly not reasonable to expect plain text e-mail to be terribly useful for longer lines. At least, not without specifically using flowed e-mail where line breaks can be relied on.

The problem is that text editing in most MUAs is soft-wrapped but the software fails to correctly hard-wrap the text later. Microsoft's very logical approach was to soft-wrap the compose window at the SAME LIMIT as hard wrap. It doesn't make quite as good use of screen space, but you know when you're trying to write something that won't transmit correctly.

E-mail should not be a chore. Battling with manual rewrap and disentangling miswrapped text should not occupy all your time trying to send mails. Fortunately, most MUAs correctly understand plain text e-mail, but a few do not, Web-based mail especially.
If this bothers you, you should simply turn off format=flowed. See http://www.ietf.org/rfc/rfc2646.txt

Add
user_pref("mailnews.send_plaintext_flowed", false);
to your user.js.

If you, yourself, don't want to SEE f=f in mails you receive, add
user_pref("mailnews.display.disable_format_flowed_support", true);
to user.js. Or:

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

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


add this to userContent.css.
> Outlook won't quote with ">"

Sure it will, but you have to set the option for it :(

(In Outlook: ) Tools -> options > preferences > e-mail options > on replies and forwards | when replying to a message [prefix each line of the original message]
(In reply to comment #42)
> If you, yourself, don't want to SEE f=f in mails you receive, add
> user_pref("mailnews.display.disable_format_flowed_support", true);
> to user.js.

For reasons completely unknown, this was already set. I don't know what it's meant to do, but it has no effect on compose windows. I also tried mailnews.send_plaintext_flowed -> false and restarted Thunderbird, but this also does not force compose windows' quoted text to be hard-wrapped to the same width as my own text (76 chars). Neither setting has any effect on the problem of incoming mail using flowed text when it fails to state that it does, and Thunderbird failing to either hard wrap the text to my outgoing limit, or even soft wrap it to the window. Despite both of the above settings, quoted reply text missing line breaks still goes miles off the side of the window, making it almost impossible to read.

This is where I'm forced to hit Rewrap so that all the text is forced back into the window, so why can't Thunderbird do this for me? The primary difference between Rewrap and reflow is that rewrap SHOULD MERGE successive lines. For example, if I snip a quote:

> A B C
> D E F
> G H I

down to:

> C
> D E F

then rewrap needs to merge the two lines:

> C D E
> F

However, this strategy causes serious damage when you use Rewrap to reflow. Reflow would insert hard line breaks according to your outgoing line length but not merge lines. For example, two lines:

A B C D E F G
T U V W X Y Z

Reflow would give you:

> A B C
> D E F
> G
> T U V
> W X Y
> Z

This won't have the effect of merging bulleted lists into a single, wrapped line and merging separate paragraphs together when they lack an intermediate blank line. Clicking Rewrap to clean up such messages is not a good step and causes substantial damage -- adjacent filled lines are treated as being part of the same paragraph and merged together.

(In reply to comment #43)
> > Outlook won't quote with ">"
> 
> Sure it will, but you have to set the option for it :(

Ah, thanks. I was pretty sure it would, though. I will pass that along.
Product: Core → MailNews Core
What an old bug! May be more annoying nowadays, because of the disappearing support for plain-text e-mails.

Although I do not know about the internals of Thunderbird, a simple question comes to my mind: Why the display of a message being composed should be different from a received message?

The incoming messages are simply beautiful: soft-wrapped, coloured according to quotes... This is all what I want, as a user, for every e-mail displayed, received or composed. (It may be even simpler to support the different standards, because no actual change would actually occur to the composed message.)

After so many manual re-wraps over years, I almost gave up using Thunderbird when I had to participate to a series of long e-mails, full of quotes. After an extensive search, I recently discovered the "mail.compose.wrap_to_window_width" setting. This workaround is not so bad, but it is really hard to find where to insert your reply when every line is black. But then, after the message is sent, it is easy to read, but too late to edit...
Confirming the issue is still reproducible with Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1.
Careful here.

Although in most cases, overly long lines are just due to carelessness, sheer rudeness, or broken clients (Apple Mail?), there are edge cases where they are appropriate.

Such would be the case with command examples embedded in an e-mail, or with log file extracts.

Introducing line breaks within these items will break them (command examples), or make them less readable (log file extracts).

So, when "fixing" this, at least make it an option. Maybe thunderbird could pop up a dialog saying "Mail to be replied to contains long lines. Break them?(X)  Leave them as is?() Always pick this choice for this sender from now on?[X]" when replying to a mail containing this situation.


As for mail.compose.wrap_to_window_width, this looks indeed like a good way to deal with replying to mails with overly long lines, thanks for the hint. And it's nice because it doesn't actually wrap the line in the mail that is sent (and so won't break any code example), but only in the display on screen. But indeed, it's a pity that quote colorization is lost. And not just on the lines that are broken, but in all quoted text. Is there any particular reason for this?
Is it rude to leave it up to the recipient's to client to make line breaks (note not paragraph ends) where appropriate? Line breaks bear no semantic, why should they be added on the sender's side?
That's what the "format=flowed" content-type attribute is good for: It allows to distinguish between "hard" (i.e., user-generated) and "soft" line breaks (i.e., the ones introduced to stay within the 76-character per line limit, which as far as I recall is a "should" but not a "must" specification).

Clients are allowed to rewrap "soft" line breaks to fit the receiving user's screen or other preferences. Unfortunately, retaining soft line breaks in quotes broke with TB 3.0 (bug 215068/bug 456053) and some e-mail clients chose to ignore the flowed-format standard (most notably Microsoft products).

Anyway, there should be a compromise possible to distinguish the user's intention from bad line breaks introduced by messages with flawed formatting.

> (comment #47) mail.compose.wrap_to_window_width

That preference merely tells the editor to ignore the indicators for quoted text, thus it is wrapped like text you've entered yourself (and consequently looses the quote-specific color), it doesn't have any effect on the message itself.
(In reply to rsx11m from comment #49)
> > (comment #47) mail.compose.wrap_to_window_width
> 
> That preference merely tells the editor to ignore the indicators for quoted
> text, thus it is wrapped like text you've entered yourself (and consequently
> looses the quote-specific color), it doesn't have any effect on the message
> itself.

Actually, I did notice that the setting didn't have any effect on the message as sent, which is how I like it. Any wrapping of quoted lines is purely for local display.

However, it is not true that it treats the quoted text as text that I entered myself, because:
 - my own text wraps at 72 columns (as it should)
 - quoted text wraps on window width
 - my own text actually is sent wrapped (as it should)
 - quoted text is still kept as it was (in long lines), see above

So, as there is already one obvious difference (wrapping to window width rather than 72 characters), why can't there be another one (different coloring)?
(In reply to Alain Knaff from comment #50)
>  - my own text wraps at 72 columns (as it should)
>  - quoted text wraps on window width

Interesting, I've only tested this briefly and didn't notice that difference.

(In reply to Boris 'pi' Piwinger from comment #0)
> > This is the beginning of a quoted line longer than
> the
> > column you chose in "Wrap plain text message at" in
> the
> > preferences.

Adding to the first part of my comment #49, that's the typical Outlook way for flowed format as they implemented just the opposite of the standard.

A line "A B C." soft-wrapped between 'B' and 'C' should look as follows, replacing a space with '_':

>_A_B_
>_C.

whereas Outlook wraps as follows, omitting the '>' in subsequent lines and reversing the trailing space definition for flowed format:

>_A_B
_C._

Thus, after fixing bug 456053, the question is if that flawed format can be auto-detected and treated as flowed for the purpose of replying, thus at least covering one part of the problem with those made-up standards of flowed plain text.
As a normal user I was searching for a very long time (years!) to solve the problem of long quoted lines when replying to certain messages and lived long with the not totally satisfying rewrap option. I also searched the net for solutions besides the rewrap option and found mostly descriptions of the problem and no other solution. This discussion seems to me to get closer to the problem than any other description of the problem, so I'm posting here.

I think I have found a way to solve the problem, at least for my personal use, and want to share it, in case somebody else finds it useful. So here we go:

Received e-mail source code looks like this (note: no format=flowed is set):

--START CODE --

[...]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
[...]

Dear Mr. Black,

this is just some text I wrote to fill =
the lines. This is still one paragraph =
with soft line breaks how certain clients =
we don't mention here are producing them.

This is the next paragraph with a soft =
line break, too.

-- END CODE --

I'm only using plain text for viewing and sending messages. My settings for wrap and format=flowed:

mail.compose.wrap_to_window_width: false
mail.wrap_long_lines: true
mailnews.wraplength: 72
mailnews.display.disable_format_flowed_support: true
mailnews.send_plaintext_flowed: false

Thunderbird displays the message with wrapping at window width, which is ok for me because I need not to scroll to read the message.

If I reply to this message with option "quote original message on reply" enabled, I get one long quoted line per paragraph. And my own typed text is wrapped at 72 characters:

-- START CODE --

[...]
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
[...]

Dear Mr. White,

I'm filling these lines with words to show
that they break at the right amount of
characters. This is still one paragraph,
let's add some more words here.

Next paragraph...

At 21.05.212 Mr. White wrote 
> Dear Mr. Black,

> this is just some text I wrote to fill the lines. This is still one paragraph with soft line breaks how certain clients we don't mention here are producing them.

> This is the next paragraph with a soft line break, too.

-- END CODE --

But I want the quoted lines to be wrapped at 72 characters like my own typed text. Using Rewrap is not a good option to achieve this, because the wrapping deletes some line breaks, which should be preserved - like the "-- " for signature or in general every short line that's not followed by a blank line is "filled up" to 72 characters.

Today, again searching for a solution, I played with the "copy" and "insert"/"insert as quoted text" options and I found a interesting solution for my problem:

- copy the whole original (plain text) message (ctrl+a, ctrl+c)
- create a new (plain text) message and paste the text (ctrl+v), the pasted text will be wrapped at 72 characters, if you apply my settings from above.
- save the message
- open the saved message and copy the text (ctrl+a, ctrl+c)
- click reply for the original message, delete the auto-inserted quoted text and
paste the copied text with right click -> insert as quoted text
- you will now see, that all quoted lines are wrapped at 72 characters (+ 2 for
quote signs "> " ? haven't count them actually).
  
So the mail looks like this:

[...]
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
[...]

Dear Mr. White,

I'm filling these lines with words to show
that they break at the right amount of
characters. This is still one paragraph,
let's add some more words here.

Next paragraph...

At 21.05.212 Mr. White wrote 
> Dear Mr. Black,

> this is just some text I wrote to fill
> the lines. This is still one paragraph
> with soft line breaks how certain clients
> we don't mention here are producing them.

> This is the next paragraph with a soft
> line break, too.

You can see now that the quoted text is exactly wrapped where the original message has soft line breaks. I don't know if this is a good solution to all received messages with soft line breaks without format=flowed set. But I think it's better than having really long quoted lines in replies, especially when you disabled format=flowed for sended mail to preserve your text as good as you can on the recipients machine (bullet lists, indentions, some programming code, etc. could be messed up with using format=flowed, I think).

Now I'm wondering, since the routines/functions/code (whatever you are calling it) you need to solve this problem are already there, if it would be possible to create a menu option (or addon) that can automatically do the mentioned steps to get wrapped quoted lines - don't get me wrong, I don't want automatic wrapping of quotes as a default, only as option for certain received mails. Or is there already an easier way to do this? Unfortunatly I'm not a programmer and not able to create a addon on myself. 

The addon AutoRewrap mentiond above is not working for TB 12, so I didn't tested it.

Perhaps somebody besides me is happy with my provided solution.

-- 
Please excuse my English, I'm not a native speaker.
At least in Thunderbird 24.2.0, rewrapping quotes is implemented in a reasonable manner [1].

The hotkey Ctrl-R for Edit > Rewrap is well chosen: it's the same as for Reply in the window that displays emails for reading. So users that prefer automatic rewrapped emails can just hit it twice. Of course Ctrl-Z will then undo the last step in the composition window. 

The *advantage of having Rewrap optional* is that you may rewrap selected parts, no selection means the entire message.

So I think this Bug is INVALID.

----
[1] there are only some tiny errors when rewrapping higher-level quotes...
Nice, thanks for the suggestion.

However, although Edit>Rewrap works nicely when applied to the whole mail, it behaves strangely when applied to only one line and paragraph.

For example, the following text:
> Si tu as une meilleure idée, pour que le sigle fasse penser à qqch dans l'informatique, je suis preneur...
> 
> (Eventuellement sur certains mots, prendre les 2 premières lettres si ça peux aider...)
> 


becomes (when rewrapping just the selection):

> Si tu as une meilleure idée, pour que le sigle fasse penser à qqch
dans l'informatique, je suis preneur...
> 
> (Eventuellement sur certains mots, prendre les 2 premières lettres
> si
ça peux aider...)

The same text, after rewrapping the _entire_ mail, turns out ok:

> Si tu as une meilleure idée, pour que le sigle fasse penser à qqch
> dans l'informatique, je suis preneur...
> 
> (Eventuellement sur certains mots, prendre les 2 premières lettres si
> ça peux aider...)
> 


Problem is, often it is not appropriate to rewrap the entire mail, if there's stuff such enumerated lists etc. elsewhere



(now lets hope that bugzilla doesn't screw up the example any further. Anybody knows about a "Verbatim" mode for bugzilla?)
good, bugzilla did indeed keep the text faithful to what Thunderbird did.

In the meantime, I found out that it works ok when selecting until a non-quoted line. If the selection stops before a quoted line, it screws it up.

This is one of the old issues but I was just informed that my replies had "chopped quoting" and indeed it had. It turns out that using Edit -> Rewrap fix the issue, but having to manually do it everytime is just tedious (the other client is mostly Apple Mail). Wouldn't it be possible to add option to rewrap automatically (accepting full consequences of it)? That would make life so much easier.

format=flowed seemed like a good idea, but it seems it's not widely adopted, and to boot - viewing mails with lines that spread across whole screen is just highly invonvenient...

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: