In bugs such as bug 32100 and bug 124175, many of us have agreed that it would be a good idea to wrap quoted text at a somewhat wider wrap column than the normal wrap column used for unquoted text. It doesn't really fall within the bounds of those existing bugs, though; we need a new bug to track this. Assigning to myself initially, and I'll post some sample patches for discussion. It may end up having to go to a mail person in the end.

There are several possible approaches here. 1. The straightforward way: wrap all quoted text to the current wrapcolumn + wrapLevel + 1 (at least for f=f style ">>> blah" style quoting). This is easy to implement but I'm leaning away from it, because it assumes that all of the correspondants being quoted also used exactly the same wrap column. 2. When in a quote, increase the "slop" in the wrapping code (see the +4 in line 1246 of nsPlainTextSerializer.cpp) substantially, so that if there is a newline coming soon, we'll take it, but otherwise we won't insert our own. This will avoid the long-short wrapping in most cases, but without imposing wrapping on long lines such as ascii art which should not be wrapped. I'm leaning toward this approach. Other options we should consider? Anything else I should keep in mind? If we go with option 2, the editor won't show it quite correctly, since we don't have that level of control over the way layout wraps text. The best we can do is set the wrapcol for quoted text to be a bit wider than normal text, and hope it comes close for most cases.

1) is really BAD. OE does it and makes quotings completely unreadable. 2) looks dangerous. It will probably work in most cases, but there always will be the thing which is just one byte too long. And then it fails. It is essential to always have a way to preserve quotings exactly as taken from the previous message. E.g., your offset from 2) might be set to 0 to disable this wrapping completely. pi

akk, I don't understand this bug. I thought, the current behaviour is as following: If the original line is fixed (nonflowed or flowed without a space at the end), add the quote mark and don't wrap at all. If the original line is flowed (f=f with space at the end), grab the whole paragraph (i.e. grab more lines until we have a fixed line and concatenate that), rewrap it so that it fits nicely within our width, incl. qoute marks. Daniel probably knows more. So, in which case do we have a problem (apart from 32100, which I see as independant)?

I keep getting called in to bugs caused by the fact that we don't wrap quoted text at all. We have all the bugs on people's replies getting stuck inside a quote block (that's editor bug 30763, but until it's fixed people are going to keep running into it), and mail output bugs like 32100 and 124175, where there are possible solutions to the specific instance; but all of them would be much less important, perhaps wouldn't be filed at all, if we wrapped quoted text as well as new text. There has always been a lot of pressure from various directions to stop enclosing quoted text in pre blocks, and just let quoted text wrap along with unquoted text; I've resisted this because I feel strongly that we should not produce long-short quotes, but a lot of people say that would be preferable to what we do now. Wrapping quoted text to a bigger margin would answer those people without producing long-short quotes. The downside is that it would make the editor bug less obvious (people who got stuck in the quote block would see their text wrap, but at slightly too wide a margin, which they might not notice though their recipients might) so it might reduce the liklihood of that getting fixed.

Disclaimer: It's late and I'm tired (both generally and of bug 32100). I think that we should avoid long-short wrapping at all costs. It's IMO the worst-case. Better too long lines than that. What about that: If you find more than one subsequent line with more than 100 (or 110) chars, and it is not a single word, apply your rewrap logic. Don't just insert a line break at 76, but rewrap at least the whole paragraph. This will break very wide ASCII-art when quoted, but I think that lines longer than 100 chars are broken anyways. This is a very dangerous change. There are tons of edge cases, lots of interop issues, and people get very enraged about such stuff. I think we are quite good about it, and we should fix the few remaining problems individually. I guess I wouldn't fix this bug.

What all this boils down to, is that we must make a design decision about how to handle quotes. AFAICS we agree that this should be handled the same way for quoting in replies/follow-ups/forwards and pastes. So maybe we should dupe bug 32100 and bug 124175 on this one? This long-short is certainly not acceptable. There is no doubt that this is completely unreadable. The eye cannot find paragaphs anymore. There is exactly nothing you win (except for compatability with Microsoft;-). So please continue to resist. I fully agree with Ben here. I don't understand the last sentence in comment 4. What is that "editor bug" which would become less obvious? Ben's idea with applying the rewrap logic sound good, but as he says, there are always the edge cases. And there are intended long lines. So I still think that we should not fix what ain't broken. As Ben says we are doing a good job right now. Trying to make the program smarter than the user will fire back. pi

Hmm -- okay, for a while there, I was under the impression that everybody thought this would be a good thing. If nobody wants it, I'll probably mark it wontfix. Leaving open for a little longer in case anyone wants to make a contrary comment.

The problem here is a possible solution to the basic problem in bug 124175. Reading the comments here it seems that it's not the best solution, and if people can't agree here, then setting this bug to wontfix is a good thing to do. But setting this to wontfix won't also fix the problem described in bug 124175, so we must go back to to bug 124175 to fix the original issue.

Okay, nobody likes this as a solution. Oh, well. WONTFIX.