From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rasmus Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Fri, 19 Sep 2014 13:53:35 +0200 Message-ID: <87tx43g728.fsf@gmx.us> References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> <877g11c8wh.fsf@gmx.us> <87wq91uhe8.fsf@newcastle.ac.uk> <8738bpc6qv.fsf@gmx.us> <87oaucvrlp.fsf@newcastle.ac.uk> <87lhpg8ooc.fsf@gmx.us> <87fvfoxcoe.fsf@ferrier.me.uk> <87y4tfzy3j.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1411127678 29672 80.91.229.3 (19 Sep 2014 11:54:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Sep 2014 11:54:38 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 19 13:54:28 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 1XUwle-0006q2-5r for ged-emacs-devel@m.gmane.org; Fri, 19 Sep 2014 13:54:26 +0200 Original-Received: from localhost ([::1]:57625 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUwld-0007t5-Ru for ged-emacs-devel@m.gmane.org; Fri, 19 Sep 2014 07:54:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUwlK-0007qu-QB for emacs-devel@gnu.org; Fri, 19 Sep 2014 07:54:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUwlE-0006yC-U3 for emacs-devel@gnu.org; Fri, 19 Sep 2014 07:54:06 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:53608) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUwlE-0006qE-Mw for emacs-devel@gnu.org; Fri, 19 Sep 2014 07:54:00 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XUwl7-0006hM-Og for emacs-devel@gnu.org; Fri, 19 Sep 2014 13:53:53 +0200 Original-Received: from 109.201.154.185 ([109.201.154.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Sep 2014 13:53:53 +0200 Original-Received: from rasmus by 109.201.154.185 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Sep 2014 13:53:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 75 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 109.201.154.185 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAAAAAByaaZbAAAAAmJLR0QA/4ePzL8AAAAJcEhZ cwAAAEgAAABIAEbJaz4AAAE1SURBVEgN1cHBYcIwEADBrehquUrUiypRJdfRPiISGwzImG9m+A+i l3+Sa+lULYjM0s4FHcFDaOeDbvEiNTgz7LzTwVrZWSmLFe2slcU7bZzpdl6VDTCZglfN5Fm3Aw4m 5U0zeKJAl0lZGHJUMimTgxXlwMYU3NhYSXlIuWZw56AZLKX8qeJOuo21UH6l3MkwOKPBjcEmhJIT TeXGziaEkBOKnWkUmxAoWVI2KZswAA3eNItdyM5kKk2eNE0eZGfjVzmNljFlVxtHsrOxiV7lZvBC dna+IbuSb8gu5AshdzaujeIu5ZrJg4NLcmRwwcFRGHwU8mzIRyYvSj5Q3pScUhZKTihLysowOTEs Xg3lAzV5SJULXUcyRXMK2hhlOVVPbqJlyzGV5ejNgxqjZQTnYiL4V34ArFoDSH8mOYQAAAAASUVO RK5CYII= User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:dwTzHDXGj3kGoPobBG36MQXELzs= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:174545 Archived-At: Hi Stephen, "Stephen J. Turnbull" writes: > Nic Ferrier writes: > > > I am torn between a much more open and distributed Emacs (which I > > suspect rms won't like) > > What's not open or distributed about Emacs? Maintaining legal > paperwork is a cost and an inconvenience, but the GPL itself legally > guarantees openness and in practice Emacs development is highly > distributed. ELPA is only going to provide more cases where people > want to "sign papers", or to gather "papers" from their coauthors. I > can't see this as a problem -- Emacs will acquire more copyrights than > it would have otherwise. > [...] Perhaps a more realistic issue is if something that should be in core cannot be. Say "next Org" (or whatever...) emerges and everybody agrees that it should be in core. Developers of "next Org" sign the paperwork. But "next Org" depends on "popular foreign library". Now you've got an issue. The Emacs tarball is no longer enough and I need to maintain a portable installation including an init file with "popular foreign repo" to get to work on, say, foreign PCs. It is an issue whether infant "next Org" knows it's "next Org". If it knows, it cannot use "popular foreign library" although it would enhance development. If it doesn't know it's "next Org" you may end up in the scenario above. At the moment 146 packages depends on s or dash and can thus not be included in core unless rewritten. Assuming they all GPL'ed it may not be a loss of freedom in the short run, but it can still have negative dynamic effects. > > But that's what we did when we introduced packages. How else did > > people think it would end? > > Huh? Packages simply are a way of making long-standing practices > (development and distribution by satellite projects) more convenient > for end users, permitting multiple development cycles for "core" > modules if desired by the core developers, and to some extent blurring > the line between core-developer and end-user convenience. Agreed. > [...] > The practical problem created by packages is (to some eyes) a blessing > in disguise. By enabling convenient separate development and > distribution of many more Lisp packages than would otherwise exist, > separate from Emacs core, it "exports" many APIs that would otherwise > be considered internal. [...]. One does not preclude the other. Last I checked Company was hosted on github. Org and Gnus live in separate repos. The API argument goes over my head. Isn't the only API in questions #autoload of functions? Or do you have Richard comment on changing functions in mind? If disputing the latter, it has been pretty convenient for Org. Nicolas (the author of ox, the org exporter) has changed all exporter in org-core and org-contrib at once, after making changes to ox. That option is very convenient when implementations have yet to reach the (theoretical) limit of efficiency — however that's measured. Cheers, Rasmus -- May the Force be with you