[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sun, 01 Jun 2003 14:35:25 -0400
Shouldn't kill-buffer-hook be permanent-local ?
After all, if you want to be told when the buffer gets killed,
you probably don't want that to be defeated by a mere change
More specifically, either you want to be told both when the buffer is killed
and when the mode changes, or you want to be told when the buffer is killed
whether or not the mode ever changes.
Looking at the various cases when kill-buffer-hook is used:
- gnus mml-destroy-buffers: called by change-major-mode-hook as well,
so permanent-localness is irrelevant.
- MH-E uses it for mh-tidy-draft-buffer (kill auxiliary buffer) and
mh-mime-cleanup (remove MIME info from a global hash table). It seems
that in both cases it would be better if the kill-buffer-hook were
permanent-local and it would at least not hurt.
- game-grid-kill-timer: also needs permanent-local.
- pong-quit: basically the same as game-grid-kill-timer.
- idlwave-kill-buffer-update: not clear which way is best, but since
the hook checks the major-mode, it probably doesn't make much of
- idlwave-shell-delete-temp-files: here also permanentness would help.
- idlwave-shell-kill-shell-buffer-confirm: doesn't make much of a difference
- register-swap-out: this turns markers into filename+offset and would
also benefit from permanentness.
- server-kill-buffer: again, making it permanent-local would help.
uniquify.el used to use it locally but stopped because it needed it
to be permanent-local. The code now uses a global hook instead
and checks whether the hook should be run using a permanent-local
I suspect a few other global uses could be made buffer-local if the
hook was permanent-local.
Any objection ?
- kill-buffer-hook permanent-local,
Stefan Monnier <=