emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BEGIN_SRC..END_SRC


From: René Kyllingstad
Subject: Re: BEGIN_SRC..END_SRC
Date: Thu, 10 May 2012 15:55:53 +0200

On Thu, May 10, 2012 at 3:05 PM, Stephen J. Turnbull <address@hidden> wrote:
René Kyllingstad writes:

 > What is the MIME approach to handling text that is perfectly fine to
 > display plainly, but can be optionally enhanced with for example syntax
 > highlighting?

The MIME approach is to *define* "text" as "content that is perfectly
fine to display plainly"!

>From RFC 2046:

  Beyond plain text, there are many formats for representing what might
  be known as "rich text".  An interesting characteristic of many such
  representations is that they are to some extent readable even without
  the software that interprets them.  It is useful, then, to
  distinguish them, at the highest level, from such unreadable data as
  images, audio, or text represented in an unreadable form. In the
  absence of appropriate interpretation software, it is reasonable to
  show subtypes of "text" to the user, while it is not reasonable to do
  so with most nontextual data.

Later it defines text/plain, and imposes the requirement that if the
MUA encounters a text/whatever it doesn't understand, it should treat
it as text/plain (unless it can't determine the character set).

This is exactly what you said, translated to RFC-ese.  Unusually sane
for an RFC. ;-)

IMHO there is a crucial difference between "perfectly fine" and "to some extent readable". It seems the MIME authors disagree.
 
 > Are MUAs supposed to have a list of all of them?

Yes!  In the sense that if the MUA wants to do something special with
the subtypes of text, then it needs to know what they all are.  If it
doesn't care, it should treat them all as text/plain. 

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

This changes the implementation from a simple catch-all to a white-list or black-list, a far less slam-dunk proposal for an esoteric MUA feature. Sigh.


-- René

reply via email to

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