From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Future role of ELPA (was: [ELPA] tramp-theme.el) Date: Tue, 16 Feb 2016 07:26:17 -0800 (PST) Message-ID: References: <87a8n20y7x.fsf@gmx.de> <87k2m60y08.fsf@mbork.pl> <871t8d26zp.fsf@gmx.de> <8760xpce7i.fsf@xsteve.at> <87vb5paxlp.fsf_-_@xsteve.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1455636438 12554 80.91.229.3 (16 Feb 2016 15:27:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Feb 2016 15:27:18 +0000 (UTC) To: =?utf-8?B?U3RlZmFuIFJlaWNow7Zy?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 16 16:27:06 2016 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 1aVhWi-0006FS-0F for ged-emacs-devel@m.gmane.org; Tue, 16 Feb 2016 16:26:56 +0100 Original-Received: from localhost ([::1]:47038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVhWd-0000a4-Px for ged-emacs-devel@m.gmane.org; Tue, 16 Feb 2016 10:26:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVhWK-0000UW-06 for emacs-devel@gnu.org; Tue, 16 Feb 2016 10:26:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVhW9-0006Jf-Ux for emacs-devel@gnu.org; Tue, 16 Feb 2016 10:26:28 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:23509) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVhW9-0006JB-N0 for emacs-devel@gnu.org; Tue, 16 Feb 2016 10:26:21 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1GFQKGM021583 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 16 Feb 2016 15:26:20 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u1GFQKLI020653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 16 Feb 2016 15:26:20 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u1GFQJb8012754; Tue, 16 Feb 2016 15:26:19 GMT In-Reply-To: <87vb5paxlp.fsf_-_@xsteve.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:200037 Archived-At: > >> As a user I really don't like that a lot of functionality is now moved= to > >> ELPA. When I install a new emacs, I have to re-install also all needed > >> packages from ELPA. A reasonable critique, I think. > >> It would be so much easier when all the batteries in emacs are still > >> included. > > > > The future plan is to move even more things into ELPA. However, parts o= f > > ELPA will be included in future Emacs tarballs, so your batteries will > > actually be there in that future. > > > > So, rather than asking whether things can move back into Emacs, the bet= ter > > question is: how should we proceed with our plan to deeply integrate EL= PA, > > so questions like this are resolved in passing. We've had some progress= in > > this direction, but there are still a few matters of process to resolve= . Exactly. I'm glad that this user (Stefan) posed the question and made know= n his use case. It should be taken into account ("resolved in passing"). > I am reading the emacs devel list. And I know that this is the direction > that is desired by most/all developers. >=20 > As I user I am not happy with that direction. > Let me try to explain it. > I use Emacs since about 20 years. I use it daily and it is my primary > interface to computer related tasks. For sure I can adopt to what ever > direction emacs goes. >=20 > I use a hand crafted .emacs and I am used to install emacs packes > manually to a site-lisp folders. >=20 > Consider a simple customization like tramp-theme. When everything is in > stock emacs: I just can change the value of a customization variable and > see what happens. >=20 > With GNU ELPA I have to install the package first and get rid of it if I > don't like it. >=20 > My main concern with GNU ELPA is that I have to install a lot of extra > packages manually using the package manager. When they are built-in they > are just there. Indeed. > So I hope that many useful features will still be shipped with Emacs as > integrated packages. I agree with you. But I also agree that it is good to modularize the Emacs code, e.g. by moving some of it to GNU ELPA. That can help both Emacs development and the use cases of some users. I agree with you that a user should be able to ask Emacs about something (e.g., a command) that has traditionally been provided with the Emacs distribution, without having to use the package system to add it. In a way, perhaps what is needed is a "super autoload" facility, that is, a more sophisticated way of making use of the package system, so that the same behavior as before a breakup into separate packages is still available seamlessly, even if under the covers packages are brought into play. The key here is "under the covers": A user should not _need_ to do anything or even to be aware that packages are being jockeyed into place automatically to accommodate an inquiry or an on-demand use of a feature. A user should not be required to (consciously, manually) use the package system at all, to interact usefully with Emacs. A user should be able to have everything that s?he had from Emacs previously on disk, locally, without jumping through any hoops. There should be no need to connect to the Internet to work with Emacs, at least regarding the large set of commands, options, etc. that has traditionally been distributed with Emacs. IOW, it should be possible for a user to use Emacs without the package system, just as easily as before. Adding the package system should be only a plus, not a plus and a minus. Users should be able to interact with Emacs in different ways, and not be obliged to get only a tiny core by default and then have to install the pieces they feel are missing. At the same time, it would be good if the Emacs code were composable from libraries in a repository such as GNU ELPA. How these two needs can best be composed I don't know. But I don't think we should be sacrificing user access to what used to be the Emacs code base on the alter of the package system. What is convenient for Emacs development and for some users some of the time should not trump the ability of other users (or the same users at other times) to interact with Emacs as they would have before the package system. If you need to activate a package to get information about `forward-sexp' or whatever, then we have lost something. That users _can_ choose not to "install" Tramp or whatever is a good thing, no doubt. But it is not necessarily a good thing that users should have to manually "install" Tramp or whatever, just to be able to talk to Emacs about it or even to make use of it. All this is a way of saying that we might need to think some more about how Emacs and Emacs Dev make use of the package system, a system that, on its own, is a good thing. It should not become a sledgehammer that makes everything in Emacs look like a nail.