Re: funny multipart/related not displaying correctly

[Dan Christensen <jdc@uwo.ca>]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Dan Christensen <jdc@uwo.ca> writes:
> 
> > The message attached below isn't displayed well by Gnus.  I suspect
> > that it is incorrect MIME.  Unfortunately, I'm getting a lot of
> > messages like this from a certain source who can't change the software
> > which generates them.  So I'm wondering:  are they in fact incorrect
> > MIME, and is there a way to get Gnus to detect this and display them
> > properly automatically?
> > 
> > The messages consist of a multipart/related with
> > type="multipart/alternative" and two sub-parts.  The first subpart
> > (part 1) is a multipart/alternative (which is correct) and the second
> > (part 2) is an image (replaced below by a text/plain part).  The
> > enclosing multipart/related shouldn't be an alternative; I want to see
> > one of the first two parts and the last part.  If I hit `K m', Gnus
> > somehow can tell this is what I want and fixes the message.  I'd like
> > this to happen automatically.
> 
> > By the way, before being fixed, `K b' only shows one button, which
> > corresponds to part 1, the alternative.  But I never see part 2.  
> > `C-u K b' fixes this, but shouldn't I see an alternative to part 1
> > with `K b'?
> > 
> > `C-d' on the message shows the correct heirarchy of parts.
> 
> gnus-mime-display-multipart-as-mixed is the variable, but maybe you
> don't want multipart/alternative displayed as mixed. So, I just added
> gnus-mime-display-multipart-related-as-mixed and
> gnus-mime-display-multipart-alternative-as-mixed.

Thanks, that helps a lot.  Is there a way I can set variables like
this (and mm-discouraged-alternatives and mm-inline-override-types) on
a per user basis?  For example, can they be functions which examine
the headers of the current article and decide how to display it?  Most
of the time I discourage html, but in this case I need to see it.

...

I've just looked at rfc2112 on multipart/related, and now I think that
the original message might be legitimate.  The
"type=multipart/alternative" in the headers actually specifies the
type of the first part, which is correct.  So now I don't see why
`K b' doesn't show me the last part.  In the actual message, rather
than the modified one I included yesterday, the last part is referenced
in the second html part, but w3 doesn't inline the image for some
reason.  (I'm using emacs 21 pretest which does correctly inline
the image after `C-u K b' or with
gnus-mime-display-multipart-related-as-mixed set to t.)
Gnus complains that there is an html error

  Error while rendering html; showing as text/plain

but with w3-debug-error set to t, there is no *HTML Debug* buffer
and w3-display-errors says:

  w3-display-errors: No HTML errors on this page!  Amazing, isn't it?

If anyone is curious about this, the original message is located
at 

  http://jdc.math.uwo.ca/bad-message

in mbox format (34k).

Thanks,

Dan

-- 
Dan Christensen
jdc@uwo.ca