Re: MIME variables

[Hrvoje Niksic <hniksic@srce.hr>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think the following should reflect the state in 0.91:
> 
> Customization
> =============
> 
> `mm-inline-media-tests'
>      This is an alist where the key is a MIME type, the second element
>      is a function to display the part "inline" (i.e., inside Emacs),
>      and the third element is a form to be `eval'ed to say whether the
>      part can be displayed inline.

I think the third element should be a function that will be called
with one argument, the MIME part.  Besides being more Lispy, it allows 
the programmer to inspect the part when making the decision.

Also, the variable could probably stand a better name.
`mm-inline-media-tests' is, uhm, less than suggestive.

> `mm-inlines-types'
>      This, on the other hand, says what types are to be displayed
>      inline, if they satisfy the conditions set by the variable above.
>      It's a list of MIME media types.

Maybe this should also allow a function, or a list of them.

> `mm-automatic-display'
>      This is a list of types that are to be displayed "automatically",
>      but only if the above variable allows it.  That is, only inlinable
>      parts are usually displayed automatically, but in the end, this is
>      up to the display agent that's using the MIME library.

Another one that could be named better.  I, for one, am not sure what
"automatical" display means, and how it differs from "inline".

> `mm-attachment-override-types'
>      Some MIME agents create parts that have a content-disposition of
>      `attachment'.  This variable allows overriding that disposition and
>      displaying the part inline.

I think this variable is misconceived, at least as far as text/plain
goes.  Many patches are rightfully sent out as "attachments", and I
don't get the button for them (I have to press `K b' explicitly, which 
is quite slow.)

Mind you, it's perfectly fine for the type to be *displayed* by
default, but the button should still be there for attachments.  Broken 
software that generates bogus content-dispositions should not be
catered to.

On the other hand, text/x-vcard probably fits this variable perfectly, 
so I guess it's only its default value I have a problem with.

> `mm-all-images-fit'
>      If non-`nil', all images will be deemed to fit into the buffer,
>      even when they don't.

This requires further explanation and possibly a rename.  How about:

    When displaying inline images that are larger than the window
    inline, XEmacs does not enable scrolling, which means that you
    cannot see the whole image.  To prevent this, Gnus tries to
    determine the image size before displaying it inline, and if it
    doesn't fit the window, Gnus will display it externally (e.g. with 
    ImageMagick or xv).  Setting this variable to nil disables this
    check and makes Gnus display all inline images as inline,
    regardless of their size.

Consequently, a good name could be something like
`mm-display-large-images-externally' or
`mm-display-externally-images-larger-than-window', or...