Re: multipart/alternative bug? [fix included]

[Toby Speight <streapadair@gmx.net>]

0> In article <vxkae55i1uq.fsf@cinnamon.vanillaknot.com>,
0> Karl Kleinpaste <URL:mailto:karl@charcoal.com> ("Karl") wrote:

Karl> I suspect it's a 5.8.8 bug.  I'm running Oort 0.03 and it displays
Karl> fine, ...

Funny, it works from my email quoting it, but it didn't work as
received.

BTW, this brokenness seems to be common to articles that have been
through the scanner's multipart filter, and it also happened with Gnus
5.8.3.

Could it be caused by an extraneous ^M in the multipart?  The original
had

> --------------InterScan_NT_MIME_Boundary
> Content-Type: multipart/alternative;
>  boundary="------------27BEBD72CFE816D2DAE0A30E"^M
>
> --------------27BEBD72CFE816D2DAE0A30E

where ^M is a CR character.  I'm wondering if Gnus's MIME parser
dislikes that.  What I see is exactly what you'd get if that header
was not there and the part defaulted to text/plain.

That would explain why it works when embedded.

[some time later]

Yes, that appears to be the case.  I think that the expression
> (memq c '(? ?\t ?\n))
in `ietf-drums-remove-whitespace' should be
> (memq c '(? ?\t ?\r ?\n))
to deal with this.  I'm not sure if there's anywhere else this appears,
but this one-liner looks safe to me.  Could someone please apply the
appropriate patch?  (ietf-drums.el, line 119).  Thanks.


Karl> but the embedded links are not active, evidently due to the fact
Karl> that W3 didn't like it enough ...

I never got that far - all rendered as text/plain, without even
loading w3.

Karl> Perhaps it's related to the bogus .jpg image -- it's not a real
Karl> image.  Even after saving it with `K o', xv(1) complains that
Karl> "there is no image data."

As I said, I cut out most of the image data (I didn't attempt to make
it a valid JPEG image, as that's not of interest).  The image in the
original was certainly okay by xv (my default for image/*).


Thanks for helping with this, Karl.