Re: feature/integrated-elpa 4f6df43 15/23: README added

[phillip.lord@russet.org.uk (Phillip Lord)]

Eli Zaretskii <eliz@gnu.org> 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