Re: Updating Elisp files while Emacs is running

[Stefan Monnier <monnier@iro.umontreal.ca>]

> OS-level package managers such as Debian's dpkg generally replace files
> unconditionally when upgrading.

I think we'd be better off discussing it with concrete cases at hand.
Let's try a few cases:
- You have Emacs-24.5 running and upgrade to Emacs-25.1.  In this case,
  making your Emacs process load files from the 25.1 version is risky,
  because there can be (and there are) incompatibilities.  You might
  still want to do it, since the incompatibilities won't always bite
  you, and it can be better than failing right away.

  Note that the files have to be elsewhere, because Debian lets you have
  both Emacs-24.5 and Emacs-25.1 installed at the same time.

- You have Emacs-24.4 running and upgrade to Emacs-24.5.  In this case,
  there should be very few incompatibilities, so it might make sense to
  try and redirect the running process to use the new 24.5 files.

  One possible solution here is for the Debian package to use
  directory names like /usr/share/emacs/24/... instead of
  /usr/share/emacs/24.4/... since Debian doesn't let you have both 24.4
  and 24.5 installed at the same time (contrary to the default Emacs
  build's presumption).

- You have ELPA package sm-c-mode-3.4 installed (and an Emacs is
  running with its load-path pointing to it) and upgrade it to
  sm-c-mode-4.0.  This can happen if you upgrade from a separate process.
  Here, there are 2 subcases:
  - you've already used sm-c-mode in this process, so most/all the files
    are already loaded.  In that case you should be fine and there's
    most likely nothing to do.
  - you haven't used sm-c-mode yet in this process, so it would be both
    desirable and likely safe to reload the new sm-c-mode-autoloads.el
    so as to redirect future uses of sm-c-mode to load from the new
    4.0 version.

I'm not sure how best to handle this, but maybe one way to accommodate
this is to add some hook to `load' to handle the situation of
a directory having gone missing.

E.g. one easy/safe hook could be a load-file-not-found-hook called when
load fails to find the file, so you could add ad-hoc code to it that
tries to detect the above situations, updates the load-path accordingly,
and tries again.

A slightly more intrusive attempt might be
a load-path-directory-not-found-hook called when a dir in load-path
doesn't exist.  This would try to solve the main problem I see with the
previous hook: when /usr/share/emacs/24.4 is missing, Emacs may
erroneously find some old/unrelated file with the same name further down
the load-path and would hence fail to run load-file-not-found-hook.
But the problem with load-path-directory-not-found-hook would then be
that it's currently considered perfectly normal for load-path to contain
non-existing directories, so it could break some setups if not done
carefully enough.


        Stefan