Bug 23679 - pine corrupts outgoing mail
Summary: pine corrupts outgoing mail
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pine   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
: 38399 (view as bug list)
Depends On:
Blocks: 38399
TreeView+ depends on / blocked
Reported: 2001-01-09 22:25 UTC by David Woodhouse
Modified: 2007-04-18 16:30 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-11 17:14:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch and specfile update (1.65 KB, patch)
2001-01-14 16:46 UTC, David Woodhouse
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2001:118 high SHIPPED_LIVE Updated PINE packages available 2001-10-02 04:00:00 UTC
Red Hat Product Errata RHSA-2001:042 high SHIPPED_LIVE : Updated pine packages available 2001-03-31 05:00:00 UTC

Description David Woodhouse 2001-01-09 22:25:39 UTC
Pine 4.30 appears to be stripping trailing whitespace from mail before
sending it.

This causes patches included in mail sent from pine to fail to apply.

Comment 1 chappa 2001-01-14 06:39:58 UTC
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.

Comment 2 David Woodhouse 2001-01-14 11:50:51 UTC
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.

Comment 3 David Woodhouse 2001-01-14 16:46:45 UTC
Created attachment 7589 [details]
patch and specfile update

Comment 4 David Woodhouse 2001-01-14 16:50:50 UTC
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.

Comment 5 chappa 2001-01-14 20:43:33 UTC
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.

Comment 6 David Woodhouse 2001-01-14 20:51:57 UTC
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.

Comment 7 chappa 2001-01-14 21:21:19 UTC
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.

Comment 8 David Woodhouse 2001-01-14 22:48:20 UTC
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?

Comment 9 chappa 2001-01-18 00:16:42 UTC
  I have a patch that I would like you to try, please pick it from my web page
send all comments to chappa@math.washington.edu.


Comment 10 David Woodhouse 2001-01-25 22:42:51 UTC
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.

Comment 11 Mike A. Harris 2001-01-28 20:44:48 UTC
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)

Comment 12 chappa 2001-02-02 23:39:09 UTC
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, 


Comment 13 David Woodhouse 2001-02-03 17:05:58 UTC
(Cut'n'paste from pine):

Fails the same test - pasting a large chunk of text into a fresh composer
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'.

Comment 14 Mike A. Harris 2001-02-06 16:25:12 UTC
This is fixed in PINE 4.33 which should appear in Rawhide real soon now.

Comment 15 David Woodhouse 2001-06-11 20:11:00 UTC
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.

Comment 16 Mike A. Harris 2001-06-23 20:45:41 UTC
*** Bug 38399 has been marked as a duplicate of this bug. ***

Comment 17 Mike A. Harris 2001-06-23 21:23:08 UTC
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?


Comment 18 Mike A. Harris 2001-07-16 08:05:40 UTC
Fixed in above -10 release

Note You need to log in before you can comment on or make changes to this bug.