[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: Removing unloaded functions from auto-mode-alist.
Date: Mon, 25 Apr 2005 00:00:44 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]