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: Wed, 19 Oct 2016 18:26:45 +0300 Message-ID: <83h988uzpm.fsf@gnu.org> 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> <87k2d4fk9m.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476890876 1397 195.159.176.226 (19 Oct 2016 15:27:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 15:27:56 +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 Wed Oct 19 17:27:52 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 1bwslr-0003b4-Us for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 17:27:12 +0200 Original-Received: from localhost ([::1]:49213 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwslu-0001Sa-5J for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 11:27:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38465) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwsln-0001SL-EY for emacs-devel@gnu.org; Wed, 19 Oct 2016 11:27:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwslj-0005rn-9o for emacs-devel@gnu.org; Wed, 19 Oct 2016 11:27:07 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53994) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwslj-0005rd-6H; Wed, 19 Oct 2016 11:27:03 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3666 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwsli-0008KQ-3A; Wed, 19 Oct 2016 11:27:02 -0400 In-reply-to: <87k2d4fk9m.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:208482 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: Stromeko@nexgo.de, emacs-devel@gnu.org > Date: Wed, 19 Oct 2016 16:09:25 +0100 > > >> 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. Sorry, I don't see why changes in file names matter. Please elaborate. If the old file org-html.el exists in directory DIR1, and the new file ox-html.el that defines the same features lives in directory DIR2, then having DIR2 in load-path ahead of DIR1 will always find ox-html.el before it finds org-html.el. If the autoloads for symbols previously defined in org-html.el now point to ox-html.el, referencing such a symbol will load ox-html.el because the regenerated autoloads say so. Right? > And, anyway, it's not possible to regenerate autoloads in core > emacs. Why not? We do that all the time, each time we rebuild Emacs. > > 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. Why do we care that the files are there if no one and nothing is loading them? Files are loaded via calls to 'load' or 'require', and implicitly by calling or referencing an autoloaded symbol. The former is taken care of by load-path: the directory with newer files will be searched ahead of the directory with older ones. The latter is taken care of by regenerating autoloads, because the autoload cookie for a symbol will now mention either the file of the same name, in which case it will be loaded from the newer directory (because of load-path reordering), or it will mention the file of a newer name which defines the symbol, and which don't exist at all in the old directory. What situation will not be caught by these two devices? > load-path is directory based. I cannot prevent files that could be > loaded from core, unless they are in one directory. You don't need to prevent that. Files that live only in the core directories will not be affected by having .emacs.d/packages/elpa/something earlier in load-path, because no file by the same name will be found in the core directories. > >> 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. It isn't fundamental, in the sense that I used this word, because it can be solved quite easily. "Fundamental" in this case means something requires a thorough redesign of many Emacs basic features.