Bug 23679

This is not a bug, it is a feature. Press M S C and scroll down to
composer-wrap-column, press "?" and read the help, the last sentence is:
"When the mail is actually sent, trailing spaces will be stripped off of
each line."

  You'll probably want to attach the patch in the future or create it, if
possible, with the diff -c command.

That's a strange place to put that important piece of information.

'diff -c' doesn't appear to help. If you strip whitespace from a context diff,
so the context lines don't match the original file, it still fails to apply (the
original was a unified diff)

Getting Linus to change his ways and accept context-less diffs or attachments
just because my mailer has started breaking his preferred method isn't really
likely to work either :)

Would it be possible to make this whitespace-stripping a config option? Or to
make the editor do it only during composition, when wrapping the line, rather
than doing it at send even on lines which were intentionally left untouched in
the editor?

It was always a very nice feature of pine that if you included a file into the
mail, and didn't edit those lines, they wouldn't be munged in any way, including
word wrapping.

Created attachment 7589 [details]
patch and specfile update

I've added a simple patch which fixes this. I was going to add a config option
for it (defaulting to off in accordance with the principle of minimal munging
and to match the behaviour of earlier versions of pine), but the pico flags word
is full, and I wasn't really sure how to go about extending it. Long long
probably doesn't work on all platforms supported by pine.

In the meantime, just commenting out the stripwhitespace() call on exit fixes
the problem, and I'm not aware of any situation where it was actually necessary
to do this.

The reason why this happens and why this information is in this
configuration option has to do with the following (not exclusively), if
you start pico with the "-w" option and say you write a line which is 100
characters long, when you justify the document to make it fit in the
required width, say 80 characters, the last character left in the
justified line will be a space, that is to say pico does not replace
the space the you wrote in that line by a "\n", it adds a "\n" between
the last space and the next word. This also happens when you are not using
the -w option and write a line too long to fit the screen, the space is not
erased, but a "\n" is added.

  The only reason I can think of why this happens is because if you
configure pine to wrap at 80 columns, not making pico delete this trailing
space would make pine display extra empty lines in the screen of the
receiver, so you want to be careful about disabling this behavior.

Occasionally displaying blank lines on the screen of the receiver is, for me,
preferable to causing patches I send to get corrupted. A cosmetic issue rather
than a correctness issue. Others' opinions may vary - often they do :)

I suspect that a fix which is acceptable for all concerned would be to make pico
delete the space at the time it wraps the line, rather than leaving it there and
calling stripwhitespace() at exit time.

What is preferable depends on which position you are. I would hate to see
too many e-mails with unnecessary empty lines in the middle of a
paragraph. I already hate to see e-mails whose width is longer than my
screen width. I suppose you'll have to attach patches where blank spaces
are crucial in the near future.

  I do, however, agree that deleting the white space at the end of the
line while composing may solve the problem. I do not know still of any
case where doing this would break pico. If I come up with a case where
this is a problem I'll post again.

Looks like it should be quite simple to change wrapword() to remove the extra
space at the end of the wrapped line. But I really don't know pico at all.
Please could you provide a patch (or some advice) to save me the pain?

  I have a patch that I would like you to try, please pick it from my web page
http://www.math.washington.edu/~chappa/pine/patches/pine4.31/wrap.patch.gz
send all comments to chappa.edu.

  Thanks!

Sorry for the delayed response. I've now tested the patch. It appears to leave
the cursor in the wrong place. It appears OK at first glance if you're entering
text right at the end of the buffer, but on word wrap, it always moves the
cursor to the end of the first word on the next line, and it always merges the
line being wrapped with the subsequent line, even though the usual behaviour of
pine is to insert a newline if it's appropriate (i.e. if you're typing at the
end of a new paragraph you're inserting, and there's a blank line between it and
subsequent text).

I'll paste this into an email, as you requested, and you'll see what I mean.

Keep up the good work guys.  ;o)  When you find a good solution, be sure
to attach it to the bugzilla entry and/or email me a copy and I'll add
it to pine immediately and release a new version for rawhide.

I have a sneaking suspicion that UW will need to make another PINE
release very soon.  4.33  ;o)

These things would likely be avoided if PINE was open source(tm).  ;o)

Thanks for the bug report. I had not had time to work on it again, but today I
did a little bit. Could you check the new patch I prepared again. It is in the
same address as before. The patch is for pine4.31, but it should apply withot
problems over new versions of Pine (including 4.33). Please get the new patch
from the same address as before, 
http://www.math.washington.edu/~chappa/pine/patches/pine4.31/wrap.patch.gz

Thanks!

(Cut'n'paste from pine):

Fails the same test - pasting a large chunk of text into a fresh composer
a
nd watching what happens to the signature. One of the dashes got eaten by
-the previous line wrap, and the second one got left at the beginning
dof this line - oh, there goes the 'd' and the 'w' from the 'dwmw2'.
Nexmt the 'm gets merged into the word 'Next'. Strange. But still not
corr2ect - ah, there goes the '2'.

This is fixed in PINE 4.33 which should appear in Rawhide real soon now.

pine-4.33-8 in Red Hat 7.1 still does it.

And for a second time I only noticed when sending Linus a large batch of
patches, which got corrupted.

*** Bug 38399 has been marked as a duplicate of this bug. ***

I have applied your patch to 4.33-10 and it seems to work ok now.
Can you test it to ensure it works as expected?

Thanks.

Fixed in above -10 release