From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added Date: Tue, 18 Oct 2016 17:47:45 +0300 Message-ID: <83mvi1ww6m.fsf@gnu.org> References: <20160916203414.25203.87032@vcs.savannah.gnu.org> <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> <87eg3ekjz2.fsf@russet.org.uk> <83vawpx677.fsf@gnu.org> <87h989ixxd.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476802133 5428 195.159.176.226 (18 Oct 2016 14:48:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2016 14:48:53 +0000 (UTC) Cc: Stromeko@nexgo.de, emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 18 16:48:49 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 1bwVgl-0006KA-O6 for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 16:48:23 +0200 Original-Received: from localhost ([::1]:42011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwVgn-0006Om-Ta for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 10:48:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwVgU-0006Ic-78 for emacs-devel@gnu.org; Tue, 18 Oct 2016 10:48:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwVgR-0003tj-5v for emacs-devel@gnu.org; Tue, 18 Oct 2016 10:48:06 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwVgR-0003tY-37; Tue, 18 Oct 2016 10:48:03 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1101 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwVgQ-0001M6-9f; Tue, 18 Oct 2016 10:48:02 -0400 In-reply-to: <87h989ixxd.fsf@russet.org.uk> (phillip.lord@russet.org.uk) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:208423 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: Stromeko@nexgo.de, emacs-devel@gnu.org > Date: Tue, 18 Oct 2016 14:33:50 +0100 > > >> The point here is that load-path is *directory* based. As it stands, we > >> cannot exclude some files in one directory. > > > > I don't see any need to exclude files. If a newer version of a > > package is installed outside of the Emacs lisp/ tree, the directory of > > that package needs to be earlier in load-path than the main lisp/ > > directory and its subdirectories. Again, not hard to arrange. > > No, this doesn't work. The point is with the new exporter, org > introduced new files. The new ox-html.el would not shadow the old > org-html.el, however you organised the path. In otherwords, the org > package changed the features that it provided over time. Look, this discussion will go nowhere constructive if you change the subject all the time. You talked about load-path, and our inability to exclude files in directories on load-path. Clearly, this only matters when Emacs wants to _load_ the file in question, and for that the order of directories in load-path is all that counts. Now you are evidently talking about a file that was already loaded, and then the user upgraded the package from which that file comes, and wants the new version to become effective without restarting Emacs, which is where the old features already loaded get in the way because the user wants their new versions. Obviously, this has nothing to do with load-path, right? > More generally, you might also concieve of a situation where a new > package replaces another. If package.el already knows how to unload the old features and load the new ones, it will continue doing this for any package, whether in or out of core. Right?