nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] extra and missing blank lines with replyfilter


From: Joel Uckelman
Subject: Re: [Nmh-workers] extra and missing blank lines with replyfilter
Date: Sun, 05 May 2013 12:58:11 -0700

Thus spake Joel Uckelman:
> Thus spake Ken Hornstein:
> > >I'm sure it's running through par. I have par installed, and when I change
> > >the $filterprogram from 'par' to 'cat', I get each paragraph of the reply
> > >as one very long line, instead of lines broken at 70-some characters. With
> > >cat, however, I'm not losing the inter-paragraph blank lines, nor am I
> > >getting blank lines inserted at the beginning.
> > 
> > Okay!  Well, that's good, at least.  That sounds like replyfilter is
> > doing what it's supposed to, at least.  So if you take the output of what 
> > you
> > get with 'cat' and feed it to 'par', does it generate the broken output?
> 
> No. When I do that, I get the output I expected to see in the first
> place: Nicely formatted paragraphs, lines between them retained, all
> quoted with >, and no spurious leading lines.
> 
> > If so, then it sounds like par is at fault ... and I'm not sure what I
> > can do about that.  Other than suggest you change your par settings.
> 
> I need par settings? I don't have any, that I know of.
>  
> > Also, if the text is sent with a non-ASCII encoding, maybe there are
> > some non-breakable spaces that are messing up par?
> 
> I see "charset=us-ascii" in the Content-Type of the MIME part.
> 
> Would it help if I sent you the actual message?
>

Follow-up for anyone playing along at home:

After quite a lot of faffing about, Ken and I figured out the problem.
There was nothing wrong with replyfilter, nor with my configuration on
my machine. The culprit was the i18n patch applied to my version of par,
which replyfilter calls. That patch converted many---but not quite all!
---of the string I/O functions in par from the narrow char versions to
the wide wchar_t versions. Mixing narrow and wide writes to the same
stream is a Bad Thing, but only produces bad output with par when its
stdout is one end of a pipe, as it is when called from replyfilter.

If you're using a stock version of par, this won't affect you, but if
you're using a par with the i18n patch, then you might want my patch for
the above problem. 

For more details (including my patch), see the bug I filed:

  https://bugzilla.redhat.com/show_bug.cgi?id=959794

-- 
J.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]