From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: kill-buffer-hook permanent-local Date: Sun, 01 Jun 2003 14:35:25 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200306011835.h51IZPn0012225@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1054492522 21059 80.91.224.249 (1 Jun 2003 18:35:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 1 Jun 2003 18:35:22 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Jun 01 20:35:20 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19MXfs-0005TQ-00 for ; Sun, 01 Jun 2003 20:35:20 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19MXw7-0005Nv-00 for ; Sun, 01 Jun 2003 20:52:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MXhq-0005br-2f for emacs-devel@quimby.gnus.org; Sun, 01 Jun 2003 14:37:22 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19MXgQ-00053q-FJ for emacs-devel@gnu.org; Sun, 01 Jun 2003 14:35:54 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19MXg5-0004Z3-2c for emacs-devel@gnu.org; Sun, 01 Jun 2003 14:35:34 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19MXg3-0004VY-Lo for emacs-devel@gnu.org; Sun, 01 Jun 2003 14:35:31 -0400 Original-Received: from rum.cs.yale.edu (localhost [127.0.0.1]) by rum.cs.yale.edu (8.12.8/8.12.8) with ESMTP id h51IZP0i012227 for ; Sun, 1 Jun 2003 14:35:25 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.12.8/8.12.8/Submit) id h51IZPn0012225; Sun, 1 Jun 2003 14:35:25 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:14568 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14568 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 of major-mode. 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 a difference. - idlwave-shell-delete-temp-files: here also permanentness would help. - idlwave-shell-kill-shell-buffer-confirm: doesn't make much of a difference either way. - 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 variable ;-) I suspect a few other global uses could be made buffer-local if the hook was permanent-local. Any objection ? Stefan