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 21:04:08 +0300 Message-ID: <83eg3cusfb.fsf@gnu.org> References: <20160916203414.25203.87032@vcs.savannah.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> <83h988uzpm.fsf@gnu.org> <87eg3ce2s1.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476900454 4954 195.159.176.226 (19 Oct 2016 18:07:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 18:07:34 +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 20:07:30 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 1bwvGf-0006fx-Ad for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 20:07:09 +0200 Original-Received: from localhost ([::1]:50147 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwvGh-00069I-FR for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 14:07:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwvEG-0004Pe-3m for emacs-devel@gnu.org; Wed, 19 Oct 2016 14:04:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwvEE-0000tT-Bp for emacs-devel@gnu.org; Wed, 19 Oct 2016 14:04:40 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwvEE-0000tN-8V; Wed, 19 Oct 2016 14:04:38 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3816 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwvEB-0003ft-Er; Wed, 19 Oct 2016 14:04:37 -0400 In-reply-to: <87eg3ce2s1.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:208486 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: Stromeko@nexgo.de, emacs-devel@gnu.org > Date: Wed, 19 Oct 2016 17:12:30 +0100 > > Eli Zaretskii writes: > > > 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? > > If everybody does the right thing. If not everybody does the right > thing, the old version gets loaded. Happened to me, it's hard to debug > and hard to work out what is going wrong. OK, so we agree that if everybody does the right thing, this will work. That's all we need at this point, because we certainly don't need to cater to packages which do the wrong thing: such packages will be fixed in no time, because they are bundled and are part of any Emacs installation. > >> 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. > > Developers do this all the time, users do not. > > We could remove, of course, put autoloads in user space under the > control of the user. This is what package.el does. Exactly. So we should use what package.el does, only extend it so it does that correctly for files under lisp/ that come from ELPA. > >> > 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? > > They are loadable. They are, but if no one is loading them, they don't matter. > Seriously, honestly, definately, I will stop defending my proposal now, > because the discussion is not advancing at all. I hope we've reached the agreement that the lisp/ tree as it is can continue be used when some packages in it come from ELPA. Thanks.