From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: BEGIN_SRC..END_SRC Date: Thu, 10 May 2012 22:05:37 +0900 Message-ID: <877gwkrxsu.fsf@uwakimon.sk.tsukuba.ac.jp> References: <871umzrvfw.fsf@gmail.com> <87wr4rqg6g.fsf@gmail.com> <83d36j59gv.fsf@gnu.org> <87r4uz58e3.fsf@sec.modprobe.de> <83aa1n57p4.fsf@gnu.org> <5D17181ED92C4552AE8D4404DD035CA0@us.oracle.com> <87vck8sfyv.fsf@uwakimon.sk.tsukuba.ac.jp> <85obq05aua.fsf@iznogoud.viz> <87r4uvs4ae.fsf@uwakimon.sk.tsukuba.ac.jp> <87397b15u7.fsf@gnu.org> <87y5p2nhc3.fsf@catnip.gol.com> <87k40lsfuv.fsf@uwakimon.sk.tsukuba.ac.jp> <87k40ljtay.fsf@gmx.com> <87fwb8sdeh.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1336655174 5513 80.91.229.3 (10 May 2012 13:06:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 10 May 2012 13:06:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?Ren=C3=A9?= Kyllingstad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 10 15:06:13 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SST4O-0003q1-Hu for ged-emacs-devel@m.gmane.org; Thu, 10 May 2012 15:06:12 +0200 Original-Received: from localhost ([::1]:36199 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SST4N-00054B-Cf for ged-emacs-devel@m.gmane.org; Thu, 10 May 2012 09:06:11 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SST4A-00051Y-D8 for emacs-devel@gnu.org; Thu, 10 May 2012 09:06:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SST41-0000Qh-V8 for emacs-devel@gnu.org; Thu, 10 May 2012 09:05:57 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:38777) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SST41-0000Pg-CF for emacs-devel@gnu.org; Thu, 10 May 2012 09:05:49 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 1F00A3FA0833; Thu, 10 May 2012 22:05:38 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D73D01A4F12; Thu, 10 May 2012 22:05:37 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta31) "ginger" 5d3bb1100832 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150417 Archived-At: Ren=C3=A9 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. ;-) > 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.