From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Tue, 19 Aug 2008 09:31:06 -0700 Message-ID: <48AAF54A.9020305@emf.net> References: <48A5BAD7.8030302@emf.net> <48A740CB.4050404@emf.net> <20080816213508.GA8530@muc.de> <87hc9ka8eg.fsf@uwakimon.sk.tsukuba.ac.jp> <20080817073124.GA1294@muc.de> <87ljyv5gy5.fsf@uwakimon.sk.tsukuba.ac.jp> <20080818101802.GA2615@muc.de> <87bpzqqk7b.fsf@uwakimon.sk.tsukuba.ac.jp> <20080818210927.GD2615@muc.de> <87wsidnxqp.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1219160493 18091 80.91.229.12 (19 Aug 2008 15:41:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Aug 2008 15:41:33 +0000 (UTC) Cc: Alan Mackenzie , hannes@saeurebad.de, rms@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 19 17:42:24 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KVTLe-0002z0-4U for ged-emacs-devel@m.gmane.org; Tue, 19 Aug 2008 17:42:18 +0200 Original-Received: from localhost ([127.0.0.1]:47173 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVTKh-0003kA-2M for ged-emacs-devel@m.gmane.org; Tue, 19 Aug 2008 11:41:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVTKc-0003k4-EG for emacs-devel@gnu.org; Tue, 19 Aug 2008 11:41:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVTKZ-0003js-O4 for emacs-devel@gnu.org; Tue, 19 Aug 2008 11:41:13 -0400 Original-Received: from [199.232.76.173] (port=48823 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVTKZ-0003jp-ET for emacs-devel@gnu.org; Tue, 19 Aug 2008 11:41:11 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:33169) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KVTKV-0003sr-1i; Tue, 19 Aug 2008 11:41:07 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.75.128] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 37194229; Tue, 19 Aug 2008 08:40:52 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <87wsidnxqp.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:102665 Archived-At: Stephen J. Turnbull wrote: > Alan Mackenzie writes: > > > The analysis from you and Tom falls short of mathematical perfection. > > Unless I'm mistaken, it focusses purely on the effects it would have on > > knowledgeable automous hackers. > > I don't speak for Tom, but my analysis falls short of perfection. As > I say, you should apply such standard to yourself, as well. > My analysis falls short of perfection as well, but by the perfect amount, of course. Seriously, Alan is being kind of read-only here. Nothing I've said limits attention to only the "effects [...] on knowledgeable [autonomous] hackers." > > You and T regard only the freedom of the informed automous hacker > > as important. > > I am very offended. I could not have imagined that you would stoop so > low. > Moreover, neither of us has written anything that suggests we even consider "informed autonomous hackers" as a special case. > > I don't think you see the point I'm making, and your analysis is > > oblivious to that point, so I disregard it. Maybe. > > No. I understand your point. "Introducing a module loader could > cause Emacs to become non-free." That's scary. > > In the light of day, though, I don't believe it's going to happen. > For the record, where Stephen and I take different tacks is that Stephen argues that scary outcome is improbable. I don't bother (since it ultimately is just speculation). Rather, I'm willing to assume (without proof, and although I believe it unlikely) that non-free add-ons will appear and be popular. That is still no argument against the feature, which ought to be judged by what *free software* it can give rise to. > > Tom, in his reply, simply failed to address this central issue of > > my post. An apology, please. > > I'm not in a position to apologize on behalf of Tom. I repeatedly stipulated that, sure, let's assume the "worst case" outcome is certain (although we don't have any good reason to believe that, really). > > Up to now, you and Tom have been asserting that calling external binaries > > is critically important and very useful. > > No, I haven't. I've said that it can be, if well designed. I like some of the use ideas Stephen is putting forward. Other use ideas: Link in a DOM library and add new lisp types for that. Link in database clients (MySQL?, DB XML, Exist, etc.). Link in incremental parsers for various programming languages (for syntax directed editing modes). Link in various scripting language interpreters. etc. It could well be that GNU Emacs is essentially moribund no matter what is done (dynamic loader or no). I certainly can't predict with certainty that a dynamic loader would be used or for what. On general principles and by analogy to the history of other systems (e.g., Apache), dynamic loaders do get used, in clever ways, and help turn a lot of separate programs into a recombinant toolkit of components. Meanwhile, they don't complicate the internals of a program very much at all and are easy to maintain. The biggest drawbacks to them are: a) It complicates bug report handling to have to always ask "What versions of which add-ons did you have loaded?" b) Creating a stable, portable, useful API requires some thought and doing a poor job of it is probably worse than not doing the job at all. -t > I've simply said I don't see enough risk, even given > the nightmarish consequences you envision, to outweigh the benefits I > see. > > > > >