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

[Eli Zaretskii]

> From: address@hidden (Phillip Lord)
> Cc: address@hidden,  address@hidden
> 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.