From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alain Schneble Newsgroups: gmane.emacs.devel Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added Date: Wed, 19 Oct 2016 21:33:42 +0200 Message-ID: <867f94qgkp.fsf@realize.ch> 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> <87k2d46vqe.fsf@Rainer.invalid> <86funsqij1.fsf@realize.ch> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476905687 23680 195.159.176.226 (19 Oct 2016 19:34:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 19:34:47 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (windows-nt) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 19 21:34:40 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 1bwwdK-0004yS-Lf for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 21:34:38 +0200 Original-Received: from localhost ([::1]:50577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwwdK-00035P-O6 for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 15:34:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwwcg-000352-Fg for emacs-devel@gnu.org; Wed, 19 Oct 2016 15:33:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwwcc-0006W5-7w for emacs-devel@gnu.org; Wed, 19 Oct 2016 15:33:58 -0400 Original-Received: from clientmail.realize.ch ([46.140.89.53]:4912) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bwwcb-0006VS-RR for emacs-devel@gnu.org; Wed, 19 Oct 2016 15:33:54 -0400 Original-Received: from rintintin.hq.realize.ch.lan.rit (Unknown [192.168.0.105]) by clientmail.realize.ch with ESMTP ; Wed, 19 Oct 2016 21:33:36 +0200 Original-Received: from myngb (192.168.66.64) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 19 Oct 2016 21:33:42 +0200 In-Reply-To: <86funsqij1.fsf@realize.ch> (Alain Schneble's message of "Wed, 19 Oct 2016 20:51:30 +0200") X-ClientProxiedBy: rintintin.hq.realize.ch.lan.rit (192.168.0.105) To rintintin.hq.realize.ch.lan.rit (192.168.0.105) X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] X-Received-From: 46.140.89.53 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:208492 Archived-At: Alain Schneble writes: > Achim Gratz writes: > >> Eli Zaretskii writes: >>> 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? >> >> You are missing that the order in which all these things happen becomes >> important. The newer autoload can only shadow the old one if it's >> processed _before_, likewise initializing other Emacs packages might >> inadvertently pull in old autoloads or definitions before things have >> been rearranged by package.el. This is not hypothetical, all of that >> has already happened and users have suffered from it. When they report >> the resulting symptoms it is extremely difficult to tease out what >> exactly happened, in which order and why, so it also wastes the time of >> those folks who want to help them. > > Of course. The order of directories in load path is always relevant. > Whatever structure we choose. I just realized you were talking about autoloads and not load path. Sorry. But the conclusion doesn't change. We just have to make sure that the old autoload definitions are no longer loaded. Alain