223279 - Inconsistent handling of multiple spaces at wrap point (flowed or not)

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Mike Cowperthwaite]

Discovered while testing bug 195513.

I tried composing emails with wrap=72, each mail consisting of five 
double-spaced lines.  Each line contains:
123456789 123456789 123456789 123456789 123456789 123456789 123456789 
(the last '9' is in column 69) followed by a variable number (1 to 5) of spaces, 
followed by "abcd".

Whether format=flowed is on or not (mailnews.send_plaintext_flowed), the caret 
behaves as described in bug 195513 comment 1.  Note also that the wrap column is 
extended near the ends of lines, as described in bug 223276.

The source for the sent mail is as follows:
  With f=f:
...123456789 abcd         <- one space between
...123456789  abcd        <- two spaces between
...123456789   abcd       <- three spaces between
...123456789              <- one trailing space after the 9
  abcd                    <- two spaces before the 'abcd'
...123456789              <- one trailing space after the 9
   abcd                   <- three spaces before the 'abcd'

  Without f=f, the last two lines are different:
...123456789              <- no trailing space
 abcd                     <- one space before the 'abcd'
...123456789              <- no trailing space
  abcd                    <- two spaces before the 'abcd'

When the message composed with f=f is viewed with f=f support enabled, and the 
window is wide enough to contain the entire width of the lines, the last two 
lines display with two and three spaces, respectively, between the last '9' and 
the 'abcd'.  If the window width is narrow enough to cause the 'abcd' to wrap to 
the next line, the last two lines display one and zero spaces before the "abcd" 
text, respectively.

Generally speaking, the end-of-line seems to be substituting for 2 or 3 spaces, 
but I think it should only substitute for 1.  The following 'expected results' 
are sort of an /ad hoc/ spec; if anyone knows of a published spec on this point, 
please post a URL.

Expected results when N spaces are entered at a wrap point:

==> With f=f turned off, the transmitted text should be as follows:
  0 spaces at the end of the line before the wrap point
  N-1 spaces at the beginning of the line following the wrap point
Currently there is one space inserted at the line end, and N-3 spaces inserted 
at the beginning of the line.  (The visual feedback at this point should be 
fixed to match, as part of bug 195513.)

==> With f=f turned on, the transmitted text should be as follows:
  1 space at the end of the line before the wrap point (for f=f)
  N-1 spaces at the beginning of the line following the wrap point.
Currently, there N-2 spaces inserted at the beginning of the line.

==> For f=f display of f=f messages, if the wrapping occurs at the soft break, 
then N spaces should be displayed between the two words.  If the wrapping does 
not occur at the soft break, then N-1 spaces should be displayed at the 
beginning of the line.

If the f=f display wrapping wraps at a point where there are N spaces between 
two words (but the source line is not broken), then N-1 spaces should be 
displayed at the beginning of the line.

These results gotten from 1.5-Final:
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

Comment 1

[Mike Cowperthwaite]

I realize that this bug is somewhat counter to bug 202195, which wants to avoid 
prefix spaces for a wrap that occurs after a period followed by two spaces.  I 
could see making a special case to subtract one space when multiple spaces (more 
than one) follow a period.

Comment 2

[Mike Cowperthwaite]

Updating the 'spec' in my original report:

==> With f=f turned on, the transmitted text should be as follows:
  1 space at the end of the line before the wrap point (for f=f)
  N spaces [**not N-1**] at the beginning of the line following the wrap point.
Currently, there N-2 spaces inserted at the beginning of the line.
[I had forgotten about space-stuffing]

==> For f=f display of f=f messages, if the wrapping occurs at the soft break, 
then [N-1 spaces should be displayed at the beginning of the line].  If the 
wrapping does not occur at the soft break, then [N spaces should be displayed 
between the two words].
[I had the logic between these two cases reversed.]

Comment 3

[Stewart Gordon]

That would suggest that every f=f paragraph should be hanging-indented by at
least one space throughout.  Is this what you meant?

And it isn't clear: is the N spaces suposed to include the space immediately
after '>' for a quoted line?

And have you seen my bug 202195 comment 13?

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> That would suggest that every f=f paragraph should be hanging-indented by at
> least one space throughout.  Is this what you meant?

Your observation is correct, and that is not what I intended.  Dang.  Allow me 
to phrase this more carefully:

==> With f=f turned on, the transmitted text should be as follows:
  1 space at the end of the line before the wrap point (for f=f)
  N-1 spaces, *plus one additional space if N>1* (for space-stuffing), at the 
beginning of the line following the wrap point.
Currently, there N-2 spaces inserted at the beginning of the line.


> And it isn't clear: is the N spaces suposed to include the space immediately
> after '>' for a quoted line?

In the case of quotes, if the message being quoted were formatted according to 
my idea, and the quoted text had N spaces at the beginning of the line 
(indicating an N-space gap between words on reflow), the quoted text would have 
a '>' followed by N+1 spaces followed by the first word.  When the quote was 
reflowed, it would show an N-space gap between the words, or an N-1-space 
indentation if at the wrap point, *not counting the margin space between the 
quotebar and the text*.

 
> And have you seen my bug 202195 comment 13?

I'm not sure how that applies.  Once the newline is entered, my expectation is 
that f=f mail will strip all the spaces preceding, to prevent the subsequent 
line from being flowed onto the end of the previous.  (And in fact, that is what 
happens with the plain-text composer.  In the HTML composer, conversion to plain 
f=f text doesn't completely strip multiple spaces: bug 125928.)

This seems OK to me -- I'm only looking to preserve multiple spaces where they 
appear within a line; trailing spaces don't add anything to the text.  (And 
non-f=f mail will just leave the spaces in place, but without reflowing that 
doesn't matter.)

Comment 5

[Stewart Gordon]

(In reply to comment #4)
> > And have you seen my bug 202195 comment 13?
> 
> I'm not sure how that applies.  Once the newline is entered, my expectation is 
> that f=f mail will strip all the spaces preceding, to prevent the subsequent 
> line from being flowed onto the end of the previous.

That comment was about how I think it should be translated into f=f, not about
how the user types it.  When it comes to newlines that were typed in, I think
it's debatable whether to assume the user knows, or doesn't know, what f=f is.

> This seems OK to me -- I'm only looking to preserve multiple spaces where they 
> appear within a line; trailing spaces don't add anything to the text.

That's interesting - I thought you wanted to preserve multiple spaces within a
_paragraph_.

Of course, we mustn't forget to leave sig separators in one piece....

Comment 6

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 7

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"