Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Lute Kamstra <address@hidden> writes:

> Consider the following situation:
>
> function 'a is autoloaded: (autoload "blabla" ...).
> function 'b is autoloaded: (autoload "other" ...).
> function 'c is defined.
> function 'd is unbound.
>
> "blabla" defines 'a, 'b, 'c, and 'd as functions.
>
> Do (require 'blabla) and then (unload-feature 'blabla).
>
> Currently, all four functions will be unbound by unload-feature.  You
> propose to let unload-feature restore both 'a and 'b to their previous
> autoloads [1].

Sure.

> But what should be done with 'c?
>
> I think restoring 'c to its previous definition would be the right
> thing to do.

Not at all.  The purpose of unload-feature is to be able to restore a
state, most particular to conserve memory.  So unload-feature should
not waste memory by keeping in effect a history of load sequences
around.  Its purpose should be confined to unloading those features
that _can_ reasonably be unloaded.  And that means no functions
whatsoever that _redefine_ stuff.  The main purpose of the autoload
restoration is to restore autoloads into the package itself, not
foreign autoloads.

I think that unload-feature should in the case of c being redefined
simply barf and refuse to unload the feature.

> But that would be quite a substantial change.  It's probably best to
> leave this alone until after the release.

Lute, _any_ change in that area is best left alone.  Richard has
already clearly stated that we are not going to fiddle with it before
the release, and I can only agree.  The current state of brokenness
has been there for a long time, and nobody really complained.  We
can't hope to get a serious amount of testing for this sort of stuff
in before the release.  And the effects might be memory leakage and
similar hard to find things that take people months to figure out.

We can't invest the time to make sure that nothing like this will
happen.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum