[Top][All Lists]

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

Re: unload-feature questions and thoughts

From: Davis Herring
Subject: Re: unload-feature questions and thoughts
Date: Wed, 10 Oct 2007 10:56:11 -0700 (PDT)
User-agent: SquirrelMail/1.4.8-6.el3.2lanl

> Yes, that's what I've been proposing. It should have to be a new hook
> for compatibility, I think.

I'm not sure the compatibility is worth the complexity.  The current
behavior is so badly documented and random (auto-mode-alist being treated
as a hook) that I would just call it a bug fix.  To check this, I went
through all the unload hooks in the sources:

delsel.el seems to think that its pre-command-hook entry will get cleared
for it, and the `remove-hook's it already does wouldn't hurt anything with
the change.

Regardless of the change, server.el needs to clear its `kill-emacs-hook'
entry (loadhist.el wouldn't, even without `server-unload-hook', because
`server-mode' is autoloaded).  It also needs to kill its C-x # binding,
suggesting that loadhist.el should perhaps sweep keymaps.  With the
change, server.el wouldn't have to do any of its extant `remove-hook's,
but they too would do no harm.

shadowfile.el needs to kill its C-x 4 s binding (again, should sweep
keymaps).  Its `remove-hook's would also be harmlessly redundant.

strokes.el wouldn't have to get rid of its `kill-emacs-query-functions'
entry itself.

whitespace.el has to have its unload function, because the functions it
adds to hooks are autoloaded.

emacs-lisp/cl.el and emacs-lisp/elp.el have meaningful unload functions too.

eshell/*.el make their unload functions customizable for some reason. 
eshell/esh-mode.el and eshell/esh-module.el are particularly odd: the
former has a default value of nil, so it just suppresses loadhist.el's
hook/a-m-a action, and the latter recursively unloads features -- it
should document that those features cannot `require' 'esh-module because
`unload-feature' would then refuse to unload it because of them even
though they would get unloaded too.

gnus/gnus-registry.el and gnus/spam-stat.el each have an interactive
unload hook that isn't necessary as an unload hook; it should be renamed
to "...-uninstall-hooks" to match its counterpart.

url/url-vars.el has a similarly needless unload hook.

So I think that the evidence is for the intuitively obvious statement that
no one knows how to use the hook.  I found no examples where the normal
heuristics would break anything, although neither did I find any examples
where the unload-hook actually broke things by suppressing the "normal
heuristics".  So I think treating it as a bug is probably the right thing
to do for simplicity: just do the heuristics regardless, and let the rare
hooks that really need to suppress them kill the variable bound for that


This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during

reply via email to

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