144842 - Wrap quoted text at a different wrap column

Status: RESOLVED WONTFIX

(MailNews Core :: Composition, defect)

Description

[Akkana Peck]

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.

Comment 1

[Akkana Peck]

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.

Comment 2

[Boris 'pi' Piwinger]

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

Comment 3

[Ben Bucksch (:BenB)]

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)?

Comment 4

[Akkana Peck]

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.

Comment 5

[Ben Bucksch (:BenB)]

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.

Comment 6

[Boris 'pi' Piwinger]

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

Comment 7

[Akkana Peck]

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.

Comment 8

[Lorenzo Colitti]

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.

Comment 9

[Akkana Peck]

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