[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Yann Hodique
Date: Thu, 10 May 2012 09:59:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

>>>>> "Stephen" == Stephen J Turnbull <address@hidden> writes:

> No, at least in this case Gmail and gmx are behaving conformantly;
> there is no requirement that an MUA implement any kind of behavior for
> the "application" content type, except providing a way to save the
> media to a file.  Which they did.

> Gnus is not incorrect, but it *is* behaving non-portably by providing
> a display method for the rare and non-portable (and probably
> unregistered) MIME type "application/emacs-lisp".

> Use "Content-Type: text/emacs-lisp" and see what happens.

As I said in a previous mail, it doesn't change anything for GMail, and
that is also (unfortunately) conformant.

Basically GMail displays *any* content-type it doesn't know about
(including the text/emacs-lisp or text/lisp variants) as an attachment
named "noname", exactly as shown in Eric's screenshot. That's obviously
a bad idea and not in the spirit of RFC 2046 (which says in 4.1.4 that
those *should* be treated as text/plain), but I'm not sure anybody at
Google really cares :)
A fallback to application/octet-stream, which is probably what's
happening here, is indeed correct...

> The MIME *approach* probably *is* portable; you didn't test it.

> The MIME *type* application/emacs-lisp is *non*-portable.  That's
> exactly what the "application" type is for.

Agreed, and again we should definitely teach Emacs/Gnus to recognize
some text/something for elisp code.
As of today, when attaching or inlining emacs-lisp code in a Gnus
message, the default value for mime type is that application/emacs-lisp,
and that's a bug.

Only that last part we can fix. So in any case, I don't believe we can
ever afford not to emit the text/plain alternative for dumb (yet
potentially even conformant) MUAs.

Given that, since Emacs is probably the only "MUA" that will ever
implement a handler for any elisp-related MIME type, whether it's
text/emacs-lisp or application/emacs-lisp is probably not that much of
an issue (but again, we should use the former)


The capacity to learn is a gift; The ability to learn is a skill; The 
willingness to learn is a choice.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]