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: Emacs Lisp's future Date: Mon, 13 Oct 2014 13:50:57 +0900 Message-ID: <87r3yco9n2.fsf@uwakimon.sk.tsukuba.ac.jp> References: <54193A70.9020901@member.fsf.org> <871tqneyvl.fsf@netris.org> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan> <838uktm9gw.fsf@gnu.org> <87h9zgarvp.fsf@fencepost.gnu.org> <83y4srjaot.fsf@gnu.org> <83r3yhiu8c.fsf@gnu.org> <83siiw9c6t.fsf@gnu.org> <83zjd3846e.fsf@gnu.org> <8738auyxke.fsf@netris.org> <874mvaoys7.fsf@uwakimon.sk.tsukuba.ac.jp> <87h9z91y52.fsf@fencepost.gnu.org> <871tqdpjoi.fsf@uwakimon.sk.tsukuba.ac.jp> <874mv91n6a.fsf@fencepost.gnu.org> <87zjd1ny1h.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1413175894 23704 80.91.229.3 (13 Oct 2014 04:51:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Oct 2014 04:51:34 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 13 06:51:27 2014 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 1XdXbS-0004SC-V2 for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 06:51:27 +0200 Original-Received: from localhost ([::1]:60123 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdXbS-0001PJ-K8 for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 00:51:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdXbI-0001P7-84 for emacs-devel@gnu.org; Mon, 13 Oct 2014 00:51:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdXbA-0005wt-Lt for emacs-devel@gnu.org; Mon, 13 Oct 2014 00:51:16 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:41346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdXb2-0005w8-Hy; Mon, 13 Oct 2014 00:51:00 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9D6CD1C391F; Mon, 13 Oct 2014 13:50:57 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 914821A2888; Mon, 13 Oct 2014 13:50:57 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:175307 Archived-At: Richard Stallman writes: > The defaults for the standard Guile primitives could be strict, > and the defaults for some Emacs Lisp functions could be flexible. Which is precisely what I proposed from the beginning[1], and as I understand his posts, it is what Mark has had in mind throughout as well. Speaking *only* for myself, I would *prefer* defaults for text coding set by Emacs to be strict, and I believe that is both in the average user's interest and not too inconvenient *in today's environment*.[2] But it should be easy for applications and modes to say to Emacs "do what you would have done in Emacs 24" and "do what you would have done in Emacs 24 *except* apply a strict(er) error handling on invalid encoding". Experience may show that my preferred default is too strict for Emacs, even today, but I believe it is the place to start. FWIW IMHO YMMV Footnotes: [1] Although my expression of that proposal seems to have been unintelligible. Sorry! [2] tl;dr UTF-8 is rapidly becoming the preferred encoding for many natural languages, although China encourages GB18030 by law and Japan and Russia both maintain their historical Babel of encodings. Protocols are both becoming stricter about validation, and using the sensible default of UTF-8. Internet protocols, where security is a very important aspect, are gradually shifting from insisting on ASCII to defaulting to UTF-8 (although often in some kind of "ASCII-armored" encoding such as BASE64 or punycode). So in general, with a few application-specific exceptions (hello, AUCTeX), both users and applications should encounter far fewer instances of broken encoding than in the era when the experiments Eli and David refer to were conducted. This is somewhat supported by the fact that at least one major dynamic language (Python) doesn't even provide an encoding detection function in its standard library. The typical range of use cases is different, granted, but editing applications (the IDLE IDE and the IPython "notebook" facility) don't seem to have issues with defaulting to "strict".