From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Ren=C3=A9_Kyllingstad?= Newsgroups: gmane.emacs.devel Subject: Re: BEGIN_SRC..END_SRC Date: Thu, 10 May 2012 15:55:53 +0200 Message-ID: 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> <877gwkrxsu.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Rene@Kyllingstad.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf30780b4eabc85304bfaefb2c X-Trace: dough.gmane.org 1336658200 31892 80.91.229.3 (10 May 2012 13:56:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 10 May 2012 13:56:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 10 15:56:39 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 1SSTr9-00016q-IA for ged-emacs-devel@m.gmane.org; Thu, 10 May 2012 15:56:35 +0200 Original-Received: from localhost ([::1]:37985 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSTr8-0001Ke-Rm for ged-emacs-devel@m.gmane.org; Thu, 10 May 2012 09:56:34 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSTqy-0001J9-Ea for emacs-devel@gnu.org; Thu, 10 May 2012 09:56:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SSTqr-0004BB-9u for emacs-devel@gnu.org; Thu, 10 May 2012 09:56:24 -0400 Original-Received: from elhaz.pair.com ([209.68.1.176]:51651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSTqr-0004AY-5h for emacs-devel@gnu.org; Thu, 10 May 2012 09:56:17 -0400 Original-Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by elhaz.pair.com (Postfix) with ESMTPSA id 1BA05B801A for ; Thu, 10 May 2012 09:56:15 -0400 (EDT) Original-Received: by vbbey12 with SMTP id ey12so2013002vbb.0 for ; Thu, 10 May 2012 06:56:14 -0700 (PDT) Original-Received: by 10.52.69.4 with SMTP id a4mr2066783vdu.87.1336658174396; Thu, 10 May 2012 06:56:14 -0700 (PDT) Original-Received: by 10.220.149.83 with HTTP; Thu, 10 May 2012 06:55:53 -0700 (PDT) In-Reply-To: <877gwkrxsu.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.68.1.176 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:150420 Archived-At: --20cf30780b4eabc85304bfaefb2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 10, 2012 at 3:05 PM, Stephen J. Turnbull wr= ote: > 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 synta= x > > 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=C3=A9 --20cf30780b4eabc85304bfaefb2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 10, 2012 at 3:05 PM, Stephen J. Turn= bull <stephen@xemacs.org> wrote:
Ren=C3=A9 Kyllingstad writes:

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

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

>From RFC 2046:

=C2=A0 Beyond plain text, there are many formats for representing what mig= ht
=C2=A0 be known as "rich text". =C2=A0An interesting characteris= tic of many such
=C2=A0 representations is that they are to some extent readable even witho= ut
=C2=A0 the software that interprets them. =C2=A0It is useful, then, to
=C2=A0 distinguish them, at the highest level, from such unreadable data a= s
=C2=A0 images, audio, or text represented in an unreadable form. In the =C2=A0 absence of appropriate interpretation software, it is reasonable to=
=C2=A0 show subtypes of "text" to the user, while it is not reas= onable to do
=C2=A0 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. =C2=A0Unusually sane<= br> for an RFC. ;-)

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

Yes! =C2=A0In 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. =C2=A0If it<= br> doesn't care, it should treat them all as text/plain.=C2=A0

=C2=A0> Wouldn't it be better with "Content-type: text/plain/el= isp" or some such?

The "plain" is redundant, because all subtypes of text fall= back to
text/plain anyway.

Redundant seems a bi= t harsh to me.

I would prefer Gmail to treat text/= rtf different from text/elisp: text/rtf should by default either be display= ed 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 esoter= ic MUA feature. Sigh.


-- Ren=C3=A9<= /div>
--20cf30780b4eabc85304bfaefb2c--