[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: |
Sat, 05 May 2012 17:48:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) |
>>>>> "Drew" == Drew Adams <address@hidden> writes:
> Bzzzzt - wrong question. The question is NOT why we don't extend or
> generalize it to other Emacs email paraphernalia besides Gnus.
> The question is why we send this crap at all in plain-text messages?
> That such markup might be useful within Org mode or Gnus or even Emacs
> generally is no reason to expose it in plain-text mail.
> We discourage the use of HTML messages in GNU mailing lists. But then
> Gnus/Org/Emacs goes and rolls its own simulacrum? And then everyone
> who is not using Emacs for mail has the obligatory privilege of seeing
> the markup?
Although the comparison with HTML is probably not that fair, 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.
I mean, doing something like this (in gnus mml markup)
<#multipart type=alternative>
<#part type="text/plain" disposition=inline>
(defun plop ()
nil)
<#/part>
<#part type="application/emacs-lisp" disposition=inline>
(defun plop ()
nil)
<#/part>
<#/multipart>
that should be rendered as nicely depending on the mailer
capabilities. Like, with lisp fontification in Emacs (Gnus at least),
and in pure-text style in Gmail for example
binBY20HbsQ75.bin
Description: application/emacs-lisp
So maybe gnus should just make it easier to compose such multipart
messages, and potentially define missing mime types if need be ?
Unless that message is broken in some widely used mailer, that is :)
Yann.
--
We say of Muad'dib that he has gone on a journey
into that land where we walk without footprints.
-- Preamble to the Qizarate Creed
- RE: BEGIN_SRC..END_SRC, (continued)
- RE: BEGIN_SRC..END_SRC, Drew Adams, 2012/05/05
- Re: BEGIN_SRC..END_SRC, Antoine Levitt, 2012/05/05
- RE: BEGIN_SRC..END_SRC, Drew Adams, 2012/05/05
- Re: BEGIN_SRC..END_SRC, Peter Münster, 2012/05/05
- RE: BEGIN_SRC..END_SRC, Drew Adams, 2012/05/05
- Re: BEGIN_SRC..END_SRC, John Wiegley, 2012/05/06
- Re: BEGIN_SRC..END_SRC, Ted Zlatanov, 2012/05/06
- Re: BEGIN_SRC..END_SRC, Miles Bader, 2012/05/07
- Re: BEGIN_SRC..END_SRC, Thien-Thi Nguyen, 2012/05/07
- Re: BEGIN_SRC..END_SRC, Ted Zlatanov, 2012/05/06
- Re: BEGIN_SRC..END_SRC,
Yann Hodique <=
- Re: BEGIN_SRC..END_SRC, Stephen J. Turnbull, 2012/05/05
- Re: BEGIN_SRC..END_SRC, Yann Hodique, 2012/05/05
- Re: BEGIN_SRC..END_SRC, Julien Danjou, 2012/05/07
- Re: BEGIN_SRC..END_SRC, Yann Hodique, 2012/05/07
- RE: BEGIN_SRC..END_SRC, Drew Adams, 2012/05/05
- Re: BEGIN_SRC..END_SRC, Martyn Jago, 2012/05/05
- RE: BEGIN_SRC..END_SRC, Drew Adams, 2012/05/05
- Re: BEGIN_SRC..END_SRC, Stephen J. Turnbull, 2012/05/07
- Re: BEGIN_SRC..END_SRC, Wolfgang Jenkner, 2012/05/07
- Re: BEGIN_SRC..END_SRC, Stephen J. Turnbull, 2012/05/08