MIME variables

MIME variables

[Lars Magne Ingebrigtsen]

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.

     This variable specifies whether a part _can_ be displayed inline,
     and, if so, how to do it.  It does not say whether parts are
     _actually_ 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.

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

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

`mm-discouraged-alternatives'
     List of MIME types that are discouraged when viewing
     `multipart/alternative'.  Viewing agents are supposed to view the
     last possible part of a message, as that is supposed to be the
     richest.  However, users may prefer other types instead, and this
     list says what types are most unwanted.  If, for instance,
     `text/html' parts are very unwanted, and `text/richtech' parts are
     somewhat unwanted, then the value of this variable should be set
     to:

          ("text/html" "text/richtext")

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


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

Re: MIME variables

[Hrvoje Niksic]

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

Re: MIME variables

[Kai.Grossjohann]

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

> `mm-inline-media-tests'
> `mm-inlines-types'
            ^
Why this `s'?  It seems inconsistent.  But maybe there's a good
reason... 

> `mm-automatic-display'
>      This is a list of types that are to be displayed "automatically",
>      but only if the above variable allows it.

In this sentence, you say that non-inlined parts are *never* displayed
automatically. 

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

Here, you say that non-inlined parts are *seldom* displayed
automatically.  Which one is right?

kai
-- 
Life is hard and then you die.

Re: MIME variables

[Kai.Grossjohann]

Hrvoje Niksic <hniksic@srce.hr> writes:

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

I think automatic display means that you see the part without having
to press the corresponding button.  Suppose I use xv to display
images, then automatic display of images means that xv is started,
err, _automatically_  ;-)

So you could say that text/html is displayed inline but not
automatically.  This way, you'd have to hit RET on the corresponding
button to have w3 render the part in the buffer.

Though the documentation seems to suggest (at least half-way) that
externally-displayed parts are never displayed automatically...

kai
-- 
Life is hard and then you die.

Re: MIME variables

[Lars Magne Ingebrigtsen]

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

Re: MIME variables

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Though the documentation seems to suggest (at least half-way) that
> externally-displayed parts are never displayed automatically...

Yup.

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

Re: MIME variables

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> > `mm-inline-media-tests'
> > `mm-inlines-types'
>             ^
> Why this `s'?  It seems inconsistent.  But maybe there's a good
> reason... 

Typo.  Should be "d".

> > `mm-automatic-display'
> >      This is a list of types that are to be displayed "automatically",
> >      but only if the above variable allows it.
> 
> In this sentence, you say that non-inlined parts are *never* displayed
> automatically. 

Yup.  Which is good, since that's the case.  :-)

> > 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.
> 
> Here, you say that non-inlined parts are *seldom* displayed
> automatically.  Which one is right?

I've now deleted this last part.  I'm not quite sure what I was
getting it here...

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

Re: MIME variables

[Hrvoje Niksic]

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

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

Please please do.  At the cost of a few more words, the code will be
much saner, and easier to replace with something else.

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

How about `mm-types-displayable-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.

How about `mm-types-displayed-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.)
> 
> But patches shouldn't be text/plain, since they aren't...

Huh?

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

Please do.  I've asked for this before, but I guess the mail got lost.

Re: MIME variables

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Please please do.  At the cost of a few more words, the code will be
> much saner, and easier to replace with something else.

Well, I agree about the sanity, but how would this make it easier to
replace it with something else?

> > > 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...
> > :-)
> 
> How about `mm-types-displayable-inline'?

I like my name better.  :-)

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

Patches should be application/octet-stream or application/x-patch. 

> > 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?
> 
> Please do.

Ok; I've removed it.

> I've asked for this before, but I guess the mail got lost.

Probably not lost, but I have 323 unread articles in nnml:misc and 168 
unread in nnml:gnus-bug.  I'll get to them Any Day Now.  :-)

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

Re: MIME variables

[Hrvoje Niksic]

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

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > Please please do.  At the cost of a few more words, the code will be
> > much saner, and easier to replace with something else.
> 
> Well, I agree about the sanity, but how would this make it easier to
> replace it with something else?

Well, I can do:

(defun my-handle-tester (handle)
  ... lots of code here ...)

...and then I can stick `my-handle-tester' as the function.  And it's
more Lispy anyway.  :-)

> > > > 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...
> > > :-)
> > 
> > How about `mm-types-displayable-inline'?
> 
> I like my name better.  :-)

What you'll name the variable "Lars Magne Ingebrigtsen"???

:-)

> > > But patches shouldn't be text/plain, since they aren't...
> > 
> > Huh?
> 
> Patches should be application/octet-stream or application/x-patch.

Yuck.  As an example, patches sent to xemacs-reviews are meant to be
read by humans as least as much as they are meant for the machine.  I
think it's perfectly fine to send them off as text/plain.

Re: MIME variables

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> (defun my-handle-tester (handle)
>   ... lots of code here ...)
> 
> ...and then I can stick `my-handle-tester' as the function.

You can just stick `(my-handle-tester handle)' into the alist.

> And it's more Lispy anyway.  :-)

I agree with that, so I've now lambdified the variable.

> What you'll name the variable "Lars Magne Ingebrigtsen"???

:-)

> > Patches should be application/octet-stream or application/x-patch.
> 
> Yuck.  As an example, patches sent to xemacs-reviews are meant to be
> read by humans as least as much as they are meant for the machine.  I
> think it's perfectly fine to send them off as text/plain.

text/x-patch would perhaps be better?  That would mean that they are
human-readable, but not plain.

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

Re: MIME variables

[Hrvoje Niksic]

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

> text/x-patch would perhaps be better?  That would mean that they are
> human-readable, but not plain.

Probably.  Yes.

Re: MIME variables

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > text/x-patch would perhaps be better?  That would mean that they are
> > human-readable, but not plain.
> 
> Probably.  Yes.

I'm just off for bed, but does the MIME RFC's say anything in
particular about doing stuff like text/x-patch?  I know that it's
common to do application/x-whatever, but I don't really recall seeing
many x-whatevers as subtypes of the text type...

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

Re: MIME variables

[David Kågedal]

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

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > > text/x-patch would perhaps be better?  That would mean that they are
> > > human-readable, but not plain.
> > 
> > Probably.  Yes.
> 
> I'm just off for bed, but does the MIME RFC's say anything in
> particular about doing stuff like text/x-patch?  I know that it's
> common to do application/x-whatever, but I don't really recall seeing
> many x-whatevers as subtypes of the text type...

Looking at RFC 2045, I see tht the BNF grammar allows subtypes of the
x-* variety. Scanning quickly through the document, I see no other
restrictions.

RFC 2046 has the following to say about text/*:

    (1)   text -- textual information.  The subtype "plain" in
          particular indicates plain text containing no
          formatting commands or directives of any sort. Plain
          text is intended to be displayed "as-is". No special
          software is required to get the full meaning of the
          text, aside from support for the indicated character
          set. Other subtypes are to be used for enriched text in
          forms where application software may enhance the
          appearance of the text, but such software must not be
          required in order to get the general idea of the
          content.  Possible subtypes of "text" thus include any
          word processor format that can be read without
          resorting to software that understands the format.  In
          particular, formats that employ embeddded binary
          formatting information are not considered directly
          readable. A very simple and portable subtype,
          "richtext", was defined in RFC 1341, with a further
          revision in RFC 1896 under the name "enriched".
[...]

   The canonical form of any MIME "text" subtype MUST always represent a
   line break as a CRLF sequence.  Similarly, any occurrence of CRLF in
   MIME "text" MUST represent a line break.  Use of CR and LF outside of
   line break sequences is also forbidden.

   This rule applies regardless of format or character set or sets
   involved.

[...]
4.1.4.  Unrecognized Subtypes

   Unrecognized subtypes of "text" should be treated as subtype "plain"
   as long as the MIME implementation knows how to handle the charset.
   Unrecognized subtypes which also specify an unrecognized charset
   should be treated as "application/octet- stream".


-- 
David Kågedal        <davidk@lysator.liu.se> http://www.lysator.liu.se/~davidk/

Re: MIME variables

[Robert Bihlmeyer]

Hi,

>>>>> On 06 Jul 1999 23:41:34 +0200
>>>>> davidk@lysator.liu.se (David Kågedal) said:

 David> Looking at RFC 2045, I see tht the BNF grammar allows subtypes
 David> of the x-* variety. Scanning quickly through the document, I
 David> see no other restrictions.

So it's not forbidden.

 David> RFC 2046 has the following to say about text/*:

 2046> (1) text -- textual information. The subtype "plain" in
 2046> particular indicates plain text containing no formatting
 2046> commands or directives of any sort. Plain text is intended to
 2046> be displayed "as-is". No special software is required to get
 2046> the full meaning of the text, aside from support for the
 2046> indicated character set.

This would imply text/plain, though.

text/x-patch is in all ways better than any application/foo-bar, because:

 2046> Unrecognized subtypes of "text" should be treated as subtype
 2046> "plain" as long as the MIME implementation knows how to handle
 2046> the charset.

I still think text/x-patch is better, since it would make it so easy
to have a different default action for patches. And they are
differently formated than plain text after all ...

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: MIME variables

[Lars Magne Ingebrigtsen]

Robert Bihlmeyer <e9426626@stud2.tuwien.ac.at> writes:

> I still think text/x-patch is better, since it would make it so easy
> to have a different default action for patches. And they are
> differently formated than plain text after all ...

I'm now defaulting *.patch to text/x-patch.

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