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 21:35:26 +0900 Message-ID: <878vh0rz75.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> <877gwkzcsm.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1336653359 18666 80.91.229.3 (10 May 2012 12:35:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 10 May 2012 12:35:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Yann Hodique Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 10 14:35:57 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 1SSSb3-0007ZV-H5 for ged-emacs-devel@m.gmane.org; Thu, 10 May 2012 14:35:54 +0200 Original-Received: from localhost ([::1]:43960 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSSb2-0001m8-UE for ged-emacs-devel@m.gmane.org; Thu, 10 May 2012 08:35:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSSav-0001l9-IR for emacs-devel@gnu.org; Thu, 10 May 2012 08:35:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SSSam-0000zS-Pj for emacs-devel@gnu.org; Thu, 10 May 2012 08:35:45 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:38393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSSam-0000yO-90 for emacs-devel@gnu.org; Thu, 10 May 2012 08:35:36 -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 7CBF73FA0835; Thu, 10 May 2012 21:35:26 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 44AAD1A4F12; Thu, 10 May 2012 21:35:26 +0900 (JST) In-Reply-To: <877gwkzcsm.fsf@gmail.com> 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:150416 Archived-At: Yann Hodique writes: >>>>> "Stephen" == Stephen J Turnbull writes: > > Use "Content-Type: text/emacs-lisp" and see what happens. > > As I said in a previous mail, it doesn't change anything for GMail, and > that is also (unfortunately) conformant. I disagree. It may be unfortunate, but it is not conformant. To quote the RFCs: 4.1.4. Unrecognized Subtypes Unrecognized subtypes of "text" should be treated as subtype "plain" as long as the MIME implementation knows how to handle the charset. Unrecognized subtypes which also specify an unrecognized charset should be treated as "application/octet-stream". -- RFC 2046 The word "should" in an RFC has a precise (and to many, surprisingly strong) meaning: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. -- RFC 2119 So it isn't optional behavior. It's required. It's simply the case that the authors of RFC 2046 could imagine stuff like Microsoft HTML, in which case you probably want to treat text/html as binary if you don't have a decent HTML rendering engine to use. However, "should" in the section 4.1.4 is not blanket permission to treat all unknown text/* as application/octet-stream, as Gmail apparently does. > Only [Gnus] we can fix. So in any case, I don't believe we can > ever afford not to emit the text/plain alternative for dumb (yet > potentially even conformant) MUAs. Maybe. But given that we know that Gmail deliberately goes out of its way to suck in our community (eg, encouraging top-posting, which has its place but it ain't here[1]), I don't really think we should consider problems with Gmail an argument against using standard constructs. If Thunderbird or nmh or mutt has issues or whatever-the-GNOMEish-MUA-is does, that's another matter. > Given that, since Emacs is probably the only "MUA" that will ever > implement a handler for any elisp-related MIME type, whether it's > text/emacs-lisp or application/emacs-lisp is probably not that much of > an issue (but again, we should use the former) No, it's the *only* issue here. If we use text/emacs-lisp, people who use conformant MUAs have a choice of font-locked display or plain text. If we use application/emacs-lisp, people who use conformant MUAs have a choice of font-locked display or saving it to a file. Footnotes: [1] Tevye: Rabbi, is there a blessing for the Czar? Rabbi: Of course, my son. (sonorously) May God bless and keep the Czar ... (with emphasis) far away from us!