[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: BEGIN_SRC..END_SRC
From: |
Yann Hodique |
Subject: |
Re: BEGIN_SRC..END_SRC |
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)
Yann.
--
The capacity to learn is a gift; The ability to learn is a skill; The
willingness to learn is a choice.
-- REBEC OF GINAZ
- Re: BEGIN_SRC..END_SRC, (continued)
- Re: BEGIN_SRC..END_SRC, Stephen J. Turnbull, 2012/05/09
- Re: BEGIN_SRC..END_SRC, Lars Magne Ingebrigtsen, 2012/05/09
- Re: BEGIN_SRC..END_SRC, Eric Schulte, 2012/05/09
- Re: BEGIN_SRC..END_SRC, Yann Hodique, 2012/05/09
- Re: BEGIN_SRC..END_SRC, Eric Schulte, 2012/05/09
- Re: BEGIN_SRC..END_SRC, Yann Hodique, 2012/05/09
- Re: BEGIN_SRC..END_SRC, Eric Schulte, 2012/05/09
- Re: BEGIN_SRC..END_SRC, Yann Hodique, 2012/05/09
- Re: BEGIN_SRC..END_SRC, Stephen J. Turnbull, 2012/05/10
- Re: BEGIN_SRC..END_SRC, Stephen J. Turnbull, 2012/05/10
- Re: BEGIN_SRC..END_SRC,
Yann Hodique <=
- Re: BEGIN_SRC..END_SRC, Stephen J. Turnbull, 2012/05/10
- Re: BEGIN_SRC..END_SRC, Yann Hodique, 2012/05/10
- Re: BEGIN_SRC..END_SRC, Miles Bader, 2012/05/10
- Re: BEGIN_SRC..END_SRC, Stephen J. Turnbull, 2012/05/14
- Re: BEGIN_SRC..END_SRC, Davis Herring, 2012/05/10
- Re: BEGIN_SRC..END_SRC, Stephen J. Turnbull, 2012/05/14
- Re: BEGIN_SRC..END_SRC, René Kyllingstad, 2012/05/10
- Re: BEGIN_SRC..END_SRC, Stephen J. Turnbull, 2012/05/10
- Re: BEGIN_SRC..END_SRC, René Kyllingstad, 2012/05/10
- Re: BEGIN_SRC..END_SRC, Stephen J. Turnbull, 2012/05/14