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 17:24:39 +0900 Message-ID: <87k344nzqw.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <83y4sk7biu.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1413188740 4373 80.91.229.3 (13 Oct 2014 08:25:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Oct 2014 08:25:40 +0000 (UTC) Cc: dak@gnu.org, rms@gnu.org, mikegerwitz@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 13 10:25:32 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 1Xdawc-0000hT-In for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 10:25:30 +0200 Original-Received: from localhost ([::1]:60803 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xdawc-0002F4-3p for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 04:25:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdawE-0002Ca-KE for emacs-devel@gnu.org; Mon, 13 Oct 2014 04:25:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xdaw7-0000RF-5J for emacs-devel@gnu.org; Mon, 13 Oct 2014 04:25:06 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:46068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xdavr-0000NQ-33; Mon, 13 Oct 2014 04:24:43 -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 145701C3979; Mon, 13 Oct 2014 17:24:40 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 064631A2888; Mon, 13 Oct 2014 17:24:39 +0900 (JST) In-Reply-To: <83y4sk7biu.fsf@gnu.org> 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:175315 Archived-At: Eli Zaretskii writes: > 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. My three cases were intended to cover the "local" case, where the user presumably has control of the files on her system. The case you are describing is covered under network streams as far as I'm concerned (YMMV, that's just the way I broke things down). > > 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. That's my main strategy, yes. We have `file-coding-system-alist' for filename cases, similar features for process and network streams, and individual modes such as AUCTeX are developed by hackers who have proved themselves able to take care of themselves. Emacs can also provide a way for individual users to opt out of the default validation mode persistently (eg, provide a global default variable and use novice mode for the opt-out). > Moreover, I don't think case (1) is as easy as you seem to think. Eli, I live in encoding hell, aka Japan, and have to deal with Chinese as well (Chinese students often use GB encodings to write Japanese). Please give me credit for extensive experience with not only broken implementations, but also bloodyminded standards bodies and users only half as witty as they think they are. Nevertheless, things are much better today than in the days when Erik Naggum declared that "Emacs has a fatal disease, and its name is 'MULE'". > In many cases, a file or a program that you think are "local" > really aren't. Just because a user thinks it local doesn't lower the risk associated with networks, although it may be somewhat lower than the open Internet. This is in the same risk class as other network streams. I suppose it would be reasonable to distinguish between Internet streams, local network streams (but only if a valid certificate was presented, otherwise there's little reason to be confident), and local files or processes. But doing that conveniently and accurately sounds like a painstaking task. > > 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. No, you didn't. I infer it from the policies for Emacs you advocate. > 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. It won't. There may be outcry, but the world has changed dramatically from the times you remember, and the outcry will be different (except for users like yourself who were there at the time and will be upset by the "regression"[1]). > I think it's naive to assume that "this time it will be different"; > experience has taught me that this attitude is ill-advised. I don't assume it. I know for a fact that the world is much more hostile than it was back then, and I think other conditions have changed enough that it's time for another experiment, hopefully with a little bit of attention to design of user interfaces in advance. > We shouldn't do that out of our own initiative based on academic > considerations and examples from PHP or whatever. You think spam, viruses, phishing, buffer overrun exploits, and the like are "academic considerations"? They aren't, and the attitude that users can and should take care of themselves is *not* a selling point in this environment, except for developers who would rather not deal with complex APIs and worse, the finicky art of providing convenient, unobtrusive, and yet flexible UI. Footnotes: [1] And I hope that group is a tiny minority, given the rapid growth in computer usage in just that decade and a half. If it turns out that greybeards like us are the majority of users, that's a sad day for Emacs and for free software.