From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Mon, 13 Oct 2014 09:02:17 +0300 Message-ID: <83y4sk7biu.fsf@gnu.org> References: <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> <87zjd9swfj.fsf@uwakimon.sk.tsukuba.ac.jp> <87oatnqpml.fsf@uwakimon.sk.tsukuba.ac.jp> <874mvdrj45.fsf@uwakimon.sk.tsukuba.ac.jp> <20141009044917.GA19957@fencepost.gnu.org> <83lhopisfr.fsf@gnu.org> <87ppe1pldu.fsf@uwakimon.sk.tsukuba.ac.jp> <8761ft5wpo.fsf@fencepost.gnu.org> <83k349b0vj.fsf@gnu.org> <83bnph96kh.fsf@gnu.org> <87ppdwo7ll.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413180172 2061 80.91.229.3 (13 Oct 2014 06:02:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Oct 2014 06:02:52 +0000 (UTC) Cc: dak@gnu.org, rms@gnu.org, handa@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, mikegerwitz@gnu.org, monnier@iro.umontreal.ca To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 13 08:02:44 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 1XdYiR-0004HJ-6C for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 08:02:43 +0200 Original-Received: from localhost ([::1]:60369 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdYiQ-0007Jk-Pt for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 02:02:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdYiK-0007Ja-22 for emacs-devel@gnu.org; Mon, 13 Oct 2014 02:02:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdYiF-0007zw-KN for emacs-devel@gnu.org; Mon, 13 Oct 2014 02:02:35 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:47131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdYiA-0007xa-1m; Mon, 13 Oct 2014 02:02:26 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NDD00600C8DQT00@a-mtaout22.012.net.il>; Mon, 13 Oct 2014 09:02:24 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD0062XCS0BN90@a-mtaout22.012.net.il>; Mon, 13 Oct 2014 09:02:24 +0300 (IDT) In-reply-to: <87ppdwo7ll.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:175312 Archived-At: > From: "Stephen J. Turnbull" > Cc: Eli Zaretskii , > dak@gnu.org, > mikegerwitz@gnu.org, > mhw@netris.org, > dmantipov@yandex.ru, > emacs-devel@gnu.org, > handa@gnu.org, > monnier@iro.umontreal.ca > Date: Mon, 13 Oct 2014 14:35:02 +0900 > > (1) The file or application is truly local, provided with the OS or > created by the user. In that case on a well-maintained system, > the encoding should be valid, as you pointed out elsewhere. > Therefore a strict policy should be transparent. (See (3) for > what I believe to be the main class of exceptions.) > > (2) The file or application was downloaded from the network. Emacs > cannot know the provenance, and so the same care should be taken > as with a network stream. > > (3) The application is trustworthy, but produces invalid encoded text > in some well-understood situations. In this case the Lisp program > should be allowed to opt out of default validation and provide its > own. Preferably only in the specific situations rather than > globally. There's also the case that the application was invoked on a remote host, and its output is passed via the network (a.k.a. "Tramp"). Not sure if those 3 cases cover that. > An example of (3) is David's case, with AUCTeX handling of TeX error > messages containing non-unibyte text.) AFAIK such applications are > quite rare nowadays. "Rare" doesn't mean unimportant to users to the degree we can ignore them. If we do want to cater to those "rare" cases, the only way of doing that is maintain a database of programs and their behaviors. We don't have that now, and I'm not sure how practical this could be, and what kind of maintenance burden it would require to keep the database up to date. Moreover, I don't think case (1) is as easy as you seem to think. The current Emacs policy is to use the locale-specific encoding, but that is just a heuristic that could easily be false, as modern distributed network-based computing doesn't lend itself well to the notion of a fixed locale with a single encoding. In many cases, a file or a program that you think are "local" really aren't. > I understand David and Eli to be of the opinion that in practice there > is insignificant risk to Emacs or its users from any form of invalid > or malicious input, from the network or local. I disagree. I never said anything like that. I simply don't have the expertise to assess the real amount of risk associated with this particular aspect of Emacs. All I can cite is my own experience. What I did say, and stand by, is that doing what you suggest is certain to cause user outcry of the kind I remember very well. I think it's naive to assume that "this time it will be different"; experience has taught me that this attitude is ill-advised. Therefore, I think Emacs should only go to the kind of strict defaults you propose if _users_ demand that, or if real-life Emacs use stories show up that demonstrate the actual danger from using the current default. We shouldn't do that out of our own initiative based on academic considerations and examples from PHP or whatever.