[O] bug#10125: RFE: require and load-path-shadowing

[Stefan Monnier]

>> I guess we could fork Emacs early on and keep this second process
>> around as a "process from which to generate new clean slates".
> I've been thinking about something like this for a while… if it worked
> at least as well as starting a new Emacs instance on all platforms, I'd
> favor this approach.

IIUC "fork" is not really an option for w32.

>> I suggested a quick&dirty solution:
>>> > E.g. we could add to bytecomp.el the ability to force `require' to
>>> > reload a package if it's not already loaded from the file that
>>> > locate-library returns.
>> I still think it's not a bad option.
> Would an advice work in this situation (given that require is a
> primitive)?

Yes, this subroutine is never directly called from C, so placing an
advice should work just fine.

> If yes, I'd like to give it a try over the weekend.  If not, I don't
> really see why require, more specifically the part that checks
> features needs to be a primitive, so maybe it could be moved partly
> to elisp.

AFAICT the only part of `require' which can't be written in Elisp right
now is the part that handles Vautoload_queue because that variable is
not exposed to Elisp (IIRC this variable is used to undo the effects of
a partially loaded file when the load bumps into an error midway
through; FWIW I'm not convinced this feature works reliably nowadays).

>> I don't see why that would introduce a difficulty.
> As long as the package is properly namespaced, why not allow for
> removing all definitions pertaining to that entire namespace (features,
> autoloads, definitions, …)?

We could try that, as well, but it would only work for those packages
that are "properly namespaced" (and there's no way to detect that
AFAIK).
Along the same lines, we could try to use unload-feature.


        Stefan