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

[David Kastrup]

Lute Kamstra <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> 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.
>
> For me, it is most intuitive/logical that unload-feature tries to
> undo the effects of loading the feature.

If it can.

> It is very uncommon that a feature redefines a function (or a
> variable), so keeping track of such cases will not waste much
> memory.

But it is very common that one loads and evals one and the same file
over and over.  We don't want to keep a history of that.

>> I think that unload-feature should in the case of c being redefined
>> simply barf and refuse to unload the feature.
>
> That's quite extreme.  And it would require you too keep track of
> redefinitions.

Of the fact that they happened.  That is about one cons cell worth of
data.  Old definitions, in contrast, can take any amount of data.

> Why not use that tracking machinery to just restore these rare
> cases?

They don't seem exactly rare to me.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum