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 17:12:30 +0100 Message-ID: <87eg3ce2s1.fsf@russet.org.uk> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476893615 8660 195.159.176.226 (19 Oct 2016 16:13:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 16:13:35 +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 18:13:31 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 1bwtUO-00080p-I8 for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 18:13:12 +0200 Original-Received: from localhost ([::1]:49600 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwtUQ-0002HW-Kg for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 12:13:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwtTo-0002GU-Ep for emacs-devel@gnu.org; Wed, 19 Oct 2016 12:12:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwtTn-0004eU-Ax for emacs-devel@gnu.org; Wed, 19 Oct 2016 12:12:36 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:56598) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwtTj-0004dM-P9; Wed, 19 Oct 2016 12:12:31 -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=EA6yl28i0iqaWg/1OU8qxjOLhYsTptvu/dKGgv/Cg/Y=; b=2zy98jOCG39hBhfCUbWUSJbgEW DQmT+dklu1/zWHMGHIJXhkqAuag8Yx2YglITDTJxhazUPwMBv2JdOKpfp7V61KAR3rhkem8oQ4N9k zBQCao5ndd8BSgrjFykNOBistRVOO0M8y2iLksXAYTG8ZzYwM6g/Wu0y7QBWlCEaKROrhq2Z8CPVZ ujjq4wLnlSXuUhBJAIq7o/cLLGdiUrSKAs5T4n9gOQ/qT+QiqJCpzfAjE+HUEJbLsEXi6h626jx2x qV7kT5lLpuDX9XlYblCAKMBerBH58ygQXGUoZMrmz5p1+G9U5/MpAH+IivvlpaqH2P8FSQGsLKZbv kaKPc+2w==; Original-Received: from janus-nat-128-240-225-60.ncl.ac.uk ([128.240.225.60]:41906 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 1bwtTi-003T6z-DL; Wed, 19 Oct 2016 17:12:30 +0100 In-Reply-To: <83h988uzpm.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 19 Oct 2016 18:26:45 +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:208483 Archived-At: Eli Zaretskii writes: >> 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. > 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. >> 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. >> > 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 should not be. It's hit me, and it's a pain. > What situation will not be caught by these two devices? Described this several times. >> 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. Also, described this several times. >> >> 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. Okay, that's fine. I don't see any fundamental difficulties in following a package.el based solution either; so far, the only issue that I have seen is "I like the directory structure the way it is", and "I don't want to see lots of directories with one or two files in core, although it's fine in user space". Seriously, honestly, definately, I will stop defending my proposal now, because the discussion is not advancing at all. Phil