Re: MIME attachment not shown

[Karl Kleinpaste <karl@charcoal.com>]

Tom Koelman <tkoelman@xs4all.nl> writes:
> it results in an extra line in front of the plain text:
> 1.  (*) text/plain          ( ) text/html           
> which wasn't there without gnus-unbuttonized-mime-types set to nil.

Right, that lets you see what the MIME analysis discovered.

> So, my guess is that Gnus correctly detects the first mime-part, and
> after detecting that it can choose whether to display the HTML or the
> plain text. Due to my preferences it displays the plain text and
> normally just ignores the HTML, which is correct.

So far, so good.

> The second mime-part however, containing the image is skipped al
> together. Is this a bug in the message, in Gnus or am I talking
> complete gibberish?

Well, you're halfway to gibberish, I'm afraid.  You evidently told
Gnus explicitly not to display text/html, something that a lot of us
do.  Having told Gnus that, it did what you wanted, ignoring the
component of that flavor.  Inline images are generally only
displayable as a function of HTML processing (other than for images
just plain inserted in their own right, as entire and independent
MIME components)

It is for this reason that I have gnus-unbuttonized-mime-types set to
nil all the time, so I am at least informed that Gnus made a choice on
my behalf, in accordance with my wishes.  If you want to see the
image, you'll have to toggle the text/html side of the posting, which
you can do with `b' (which takes as argument the part number to be
displayed, and part 1 is of course the default).

If you still don't see the image, you might experiment with whether 
(setq gnus-mime-display-multipart-related-as-mixed t)
helps you out.  This is a bug workaround due to problems in the past
of "related" components not being dealt with properly -- it makes
images intended as inline (especially background images) be displayed
after the intended component entirely, as though they were just
another of a "mixed" set.