Re: BEGIN_SRC..END_SRC

["Stephen J. Turnbull" <stephen@xemacs.org>]

René Kyllingstad writes:

 > IMHO there is a crucial difference between "perfectly fine" and "to some
 > extent readable". It seems the MIME authors disagree.

I rather doubt that they disagree with you. The MIME authors simply
thought about it carefully and came to the conclusion that (1)
subtypes of text are necessary for enhanced display, which is *very*
desirable, while (2) implementation costs imply that not all MUAs will
implement all subtypes, and (3) the dividing line between "perfectly
fine" (and therefore not urgent to implement) subtypes and "to some
extent readable" (and therefore of relatively high implementation
priority) can and must be delegated to implementers, both of the types
themselves (who are the ones who register the MIME content type, see
below) and of the MUAs that interpret them.

 > >  > Wouldn't it be better with "Content-type: text/plain/elisp" or some
 > > such?
 > >
 > > The "plain" is redundant, because all subtypes of text fall back to
 > > text/plain anyway.
 > 
 > Redundant seems a bit harsh to me.
 > 
 > I would prefer Gmail to treat text/rtf different from text/elisp: text/rtf
 > should by default either be displayed with the markup interpreted or as a
 > download, whereas text/elisp should be displayed as text/plain.

Sure, but that's up to Gmail; if Gmail doesn't do it your way, you can
(a) live with it, (b) get Gmail to change it, (c) change to a
different MUA that does it your way, or (d) write your own MUA that
gets it right.  The needed information is there; adding yet another
level of subtype doesn't improve the situation.  Note that you just
can't win: if the designers of RTF agreed with you, they would have
registered the content type as application/rtf rather than text/rtf.
I gather that they disagree with you, and so if there *were* a
text/plain/emacs-lisp, you'd also see text/plain/rtf, and there's no
improvement.

That is, you *can* get what you want under the standard as written, at
some cost.  And the way the standard is written, in any standard-
conforming MUA, we both get something we can work with, even though we
don't agree on optimal behavior (I want to see text/rtf, you don't).