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: Wed, 19 Oct 2016 16:09:25 +0100 Message-ID: <87k2d4fk9m.fsf@russet.org.uk> References: <20160916203414.25203.87032@vcs.savannah.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> <87eg3ekjz2.fsf@russet.org.uk> <83vawpx677.fsf@gnu.org> <87h989ixxd.fsf@russet.org.uk> <83mvi1ww6m.fsf@gnu.org> <87wph5fw0w.fsf@russet.org.uk> <838ttlwodt.fsf@gnu.org> <878ttl3342.fsf@Rainer.invalid> <8360opwjs2.fsf@gnu.org> <8760oosrn8.fsf@russet.org.uk> <83shrsvj3g.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476889850 10263 195.159.176.226 (19 Oct 2016 15:10:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 15:10:50 +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 Wed Oct 19 17:10:46 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 1bwsVd-00009s-W1 for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 17:10:26 +0200 Original-Received: from localhost ([::1]:49124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwsVg-0000vq-6Y for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 11:10:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwsVU-0000tq-SV for emacs-devel@gnu.org; Wed, 19 Oct 2016 11:10:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwsVT-0005zB-QZ for emacs-devel@gnu.org; Wed, 19 Oct 2016 11:10:16 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:52244) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwsVP-0005aC-9L; Wed, 19 Oct 2016 11:10:11 -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=JabVgYDu4Tq9HnIlv7IQFMGzaBPdO2XD8iyDJNo42wo=; b=1RUePGOz6HbgHP5qAhmWMNMjyF 3O36QFz5v1ScrihVGyGvWlvbnjC+VDp7WLmmkMIqQK81pg+C3Sm6ZFqKQkELKXQ23Y/iopM+Qs7GQ xAesmT5EeRWEe6WgyfiCrVFI7EmjWXHTtANqEEGTWnuyjOD5fXSTyuyCXtFHnfZFYy5CPNPb7lOR9 3ta8teHYdTGjFFSLbUtgJC2KBhgoGcPuCzW9tg6E7hx5ROrUUCIWdvEr46ULLFiuB9BEblaTV2PBT caEhF4HUTOLmwK0DBWGNruVRSR8GAbrf/dhXfiaMro0JOy081PLXpZacXO8ygkkiBvFMYuZ2BzQDL sQ6tFLwg==; Original-Received: from janus-nat-128-240-225-60.ncl.ac.uk ([128.240.225.60]:45968 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 1bwsUg-003FL5-Dg; Wed, 19 Oct 2016 16:09:26 +0100 In-Reply-To: <83shrsvj3g.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 19 Oct 2016 11:28:03 +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:208479 Archived-At: Eli Zaretskii writes: >> Eli, I think you are not taking the time here to understand the problem. >> Both Achim and I have thought the issue through > > Those kinds of remarks are hardly constructive. Please assume that > I've thought the issues through as best I could, If you will assume the same, yes, of course. >> and it restarting Emacs were the solution then neither of us would, >> I expect, be complaining. > > I don't see why restarting won't be a solution. If load-path was > re-arranged to put the latest version of a package first, and the > package's autoloads are on a file that has been regenerated, what else > is missing to make restart the correct solution? Again, only if the file names have not changed between one release and the next. This is an assumption which is not true. And, anyway, it's not possible to regenerate autoloads in core emacs. >> As Achim says, an org-html in the core installation cannot be removed >> because it comes as part of a packaged Emacs and needs admin >> privilleges; again, can be done, but not very good practice. The >> org-html in core can be shadowed but only by another file called >> org-html. More recent versions of org do not contain such a file. > > If load-path is rearranged when a newer version of Org is installed, > and org-loaddefs are regenerated, then, after a restart, any 'load' > and 'require' will find the new files first, and the old ones will be > effectively invisible to Emacs. Right? No. They are still there, and are still visible, as long as they are in the load path. >> There are solutions to this, many of them hacky. The simplest solution >> is to NOT include the directory containing the old version of org in the >> load-path. > > That solution will only work for packages in their own directories. Yes, hence my assumption my argument that packages in their own directories is a good thing. > We want to have a solution that works even for files in common > directories. I think rearranging load-path and regenerating the > autoloads will solve that as well. As discussed rearranging the load path does not solve the problem, and regenerating the autoloads isn't possible. >> It will not, and does not. > > Why won't it? (The "does not" part just means package.el doesn't > currently do that, AFAIU, but it can be extended to do it.) load-path is directory based. I cannot prevent files that could be loaded from core, unless they are in one directory. >> I will leave it there. If neither you or John want to go this way, I >> will stop. > > I think we both indicated that we want to go this way, we just don't > want the Lisp files scattered among dozens of directories, each one > with a single file. Yes, this is a goal that is harder to achieve, > but I don't yet see any fundamental difficulties on that path, just > some more work. The fundamental difficult is that we are supporting two different file arrangements for any package present in core that can also be installed from ELPA. > I think making such a change incrementally is worse than doing it at > once, as far as the directory structure is concerned. We don't want > to change the directory structure several times, ideally not even > once. But if some change is required, it should be done in one go, so > we need to decide on the structure up front. That, of course, is also a possibility, and one that I would be happy to consider. Phil