Re: funny multipart/related not displaying correctly

[ShengHuo ZHU <zsh@cs.rochester.edu>]

Dan Christensen <jdc@uwo.ca> writes:

[...]

> 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 think there is no such built-in function.

> 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. 

The handle is not displayed, so `K b' has no effect.

> 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).

This often happens in Emacs 21, not other ones. W3 throws the error
but doesn't give info.

ShengHuo