From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added Date: Tue, 18 Oct 2016 11:52:17 +0100 Message-ID: <87eg3ekjz2.fsf@russet.org.uk> References: <20160916203414.25203.87032@vcs.savannah.gnu.org> <831szrhwsr.fsf@gnu.org> <8760p12qzw.fsf@russet.org.uk> <83vax0en1u.fsf@gnu.org> <87pon5ek3q.fsf@russet.org.uk> <87twcgttjf.fsf@russet.org.uk> <86a8e7symk.fsf@realize.ch> <8737jzl4u9.fsf@russet.org.uk> <8337jz8dg8.fsf@gnu.org> <83insv3tnl.fsf@gnu.org> <83d1j33qgg.fsf@gnu.org> <87wph96cto.fsf@russet.org.uk> <831szh3iq4.fsf@gnu.org> <87mvi5spl9.fsf@Rainer.invalid> <83mvi51y3b.fsf@gnu.org> <87instslxu.fsf@russet.org.uk> <83inst1vut.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476788302 22736 195.159.176.226 (18 Oct 2016 10:58:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2016 10:58:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: Stromeko@nexgo.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 18 12:58:18 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwS63-000591-57 for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 12:58:15 +0200 Original-Received: from localhost ([::1]:40306 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwS65-0000pt-8Q for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 06:58:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwS13-0005ld-Rx for emacs-devel@gnu.org; Tue, 18 Oct 2016 06:53:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwS12-0004yK-RJ for emacs-devel@gnu.org; Tue, 18 Oct 2016 06:53:05 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:52218) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwS0y-0004h7-BL; Tue, 18 Oct 2016 06:53:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From; bh=+Lm5+SQV9P3yaUnpfYzbt5ZD8S70T8I0YeJT5Mar690=; b=t4crhOaQinR4iR6iCYABlQfFGI +ZIFf9MzWWGFkwKxiRR3ABupA/h2dHS4RRxBVi2qRlHDjbN3lN3NDQ07FDb1J77aGptm/J5EPUKV1 V6TLRHiscQphBBrjJR+RdAUn358JCpa8mInMd6VxMsIPee9Q0oDrdrTAGOQ3324hkOwGGxljRF1Lo 9nJ3zvoFB1E08V2S7c7+jUJfd76S9fi8mOFx7sklBoZ/Zgb6KFnUH5HDeDnN+H4gkUYoGSNLv3Qs0 /BVXCAb3mYm79r6w7zGaPjiCBOtZvu3XA18JO/E6t2G3jjbGadov8XPRGmF5XZXYHrBrPBIj/UNWc 0Mu3qqUA==; Original-Received: from janus-nat-128-240-225-60.ncl.ac.uk ([128.240.225.60]:61108 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1bwS0I-001Nct-Ch; Tue, 18 Oct 2016 11:52:18 +0100 In-Reply-To: <83inst1vut.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 15 Oct 2016 18:21:30 +0300") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 31.216.48.48 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:208404 Archived-At: Eli Zaretskii writes: >> package.el solves the problem that org-html.el no longer exists simply >> by not adding org-mode-1.6 to the load path. Nor does it load >> "org-autoloads.el". So, even though org-html.el is still around on the >> hard drive, it is ignored by emacs. > > The same can be done with any other directory structure, in two steps: > (1) put the new directory first in load-path, and (2) don't load > org-autoloads.el. Right? Apologies if I have replied to this already -- getting confused. Yes, it could be. >> Now, as it happens, with the current directory organisation of Emacs, we >> can solve the problem anyway, by doing the same trick in core. But, >> currently, we don't. > > That's exactly what I meant: we can do this with any directory > structure. IOW the directory structure is not relevant to this issue. I think that this is incorrect. In this case, we can do this with the directory structure that we have at the moment, and for org-mode, because org-mode is a) in a directory of it's own and b) has it's own loaddefs. This is not true for many of the files in ./lisp. The point here is that load-path is *directory* based. As it stands, we cannot exclude some files in one directory. >> And this could only work for org.el *because* org is in it's own >> directory with its own autoloads file. For seq.el, for instance, it will >> not work. > > So one solution would be to provide a separate autoloads file for each > package that lives on ELPA. That again has nothing to do with the > directory structure. Right? (There could also be other solutions.) I think that it is evident that there could be other solutions. Emacs is Turing complete so any computable solution that you can image is possible. The question is which is easiest. package.el already does all of this. >> There are a few other things that package.el does, which it would be >> shame to loose. It checks dependencies for instance. So, say, I >> installed assess.el into Emacs core using package.el as I suggest, and >> it requires a newer version of seq.el than is available, package.el will >> bitch about this very early. > > I don't see why we'd have to lose this. No one said we are throwing > away package.el. We are talking about _extending_ it. Just so that we can keep a particular directory structure? >> Bottom line: package.el is a better way of handling packages than core >> which is a legacy. Moving wholesale to it is probably not worth the >> effort (at least not in the short term). But supporting it in core >> definately is. > > We need to adapt package.el to the new needs. It was not written with > these goals in mind, so it needs to learn new tricks. Throwing it > away is not acceptable, but neither is blindly accepting its current > assumptions, which were not designed for the use case we are > discussing. No, but it's current behaviour makes a lot of sense to me and is, I think, better than the monolithic structure we have in ./lisp. Yes, it needs to be taught new tricks and it needs to be -- it can't cope with texinfo files, for instance. Phil