Problems with inlining images in Emacs 20

[Barry Fishman <barry_fishman@acm.org>]

I'm not an expert at gnus mime processing but:

Concerning mm-decode.el:

It seems wrong to put the image file wildcard "image/.*" as a part of
mm-inlined-types.  This seems to mean that any image type not caught
by the mm-inline-media-tests will be just placed inline.  Shouldn't
one assume that if an image is not of a known type, the Emacs 21's
will probably not know what to do with it, and if they did, at least
the mm-valid-and-fit-image-p test should be made.

In Emacs 20, inlined images do not look very pretty, and since they
are inlined there isn't even a button to save them to a file or even
get rid of them.  This is a real pain.


Concerning gnus-art.el:

In gnus-display-mime, The mm-dissect-buffer test is always done in its
strict mode.  There seems to be messages that get correctly dissected
with the strict option off, but using

     (or (mm-dissect-buffer) (mm-uu-dissect) (mm-dissect-buffer t))

about line 3776 seems to cause emacs to break (although not to crash).
Is this why strict mime processing is not a customization option?

I have been working on a `gnus-force-mime' which can be called
interactively, when you are seeing a message which is obviously
intended to be mime, but is missing something like a mime version
header.  It would be available like "C-u g" which in a sense does the
opposite in shutting off all processing.  Does this seem reasonable?
Is something like this already done?

In general:

I don't like encouraging the use of invalidly formatted mime messages,
by just having mail/news readers accept them without comment.
However, I can't just ignore mail that is incorrectly formatted, and
disassembling them by hand is a real pain.

Barry Fishman