Re: MIME variables

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Hrvoje Niksic <hniksic@srce.hr> writes:

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

Yes, but it's more convenient the current way.

The default value is

    ("image/gif" mm-inline-image (mm-valid-and-fit-image-p 'gif handle))
    ("image/tiff" mm-inline-image (mm-valid-and-fit-image-p 'tiff handle)) 

[...]

    ("text/html" mm-inline-text (locate-library "w3"))

Of course, I could just wrap all these in `lambda's, which would make
things more better, although more verbose.  As well as making the
magic `handle' dynamic variable explicit.

I dunno.

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

Well, they are tests to see whether media can be displayed inline...
:-) 

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

The idea is that the first variable says whether something is
possible, and if so, how to do it, while the second says whether we
want it or not, so I don't see any need to re-specify a function here.
The first variable will probably not be altered by the user, while the
second probably will be.

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

In a Gnus context, this specifies which types that are displayed when
you select an article.  This is usually a subset of the types that can 
we want to be inlined.

For instance, we can inline audio/*, but we don't want it to be
displayed automatically.

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

But patches shouldn't be text/plain, since they aren't...

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

I agree with that.  Perhaps I should just alter the default to exclude 
text/plain, and then the user who want to cater to such software can
add it?

> > `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:

I've included your version.

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

`mm-inline-large-images'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen