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

Attachment: 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

reply via email to

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