emacs-devel
[Top][All Lists]
Advanced

[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: Sat, 05 May 2012 19:12:25 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

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

> Yann Hodique writes:

>> I do agree that it's bad email practice. More importantly, I'm
>> wondering how it would not be better to leverage the existing
>> RFC1341 that any decent mailer should implement.

> Good idea, but poor implementation.  IMSEO this:

Definitely. That was only meant as a quick and dirty POC. For real life
usage, I'd definitely rather rely on some program (gnus) doing the right
and clean thing :)
Btw I would even be perfectly happy with writing org-mode blocks and
letting gnus figure out how to make it nice.

The point of using application/emacs-lisp was just to demonstrate
something that works *today*. text/lisp or text/emacs-lisp would
definitely be cleaner, but they're not recognized as elisp code by gnus
as of now.

> Now, RFC 2046 section 4.1.4 strongly recommends that an unrecognized
> text type be treated as text/plain, so the multipart alternative
> structure is redundant with my preferred content type of
> text/emacs-lisp.  So any MUA that properly respects the standard will
> just DTRT at no cost.

Yep, except that at least GMail doesn't, and it definitely qualifies as
"widely used". Instead, it displays its infamous "noname"
pseudo-attachment, even though the part was supposed to be inlined in
the first place (which is broken in so many ways it's not even
funny). So I agree in theory, but that doesn't seem practical.

Yann.

-- 
Seek freedom and become captive of your desires.
Seek discipline and find your liberty.

  -- The Coda




reply via email to

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