From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.bugs Subject: bug#5293: 23.1; unload-feature on buffer-local hooks Date: Fri, 15 Jul 2011 13:24:00 +0200 Message-ID: References: <87hbr4p67t.fsf@blah.blah> <871uxsl778.fsf@blah.blah> <87oc0wdiy9.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1310729131 9115 80.91.229.12 (15 Jul 2011 11:25:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2011 11:25:31 +0000 (UTC) Cc: Kevin Ryde , 5293@debbugs.gnu.org To: =?UTF-8?Q?=C5=A0t=C4=9Bp=C3=A1n_?= =?UTF-8?Q?N=C4=9Bmec?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 15 13:25:27 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QhgWM-0006V4-9O for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Jul 2011 13:25:26 +0200 Original-Received: from localhost ([::1]:46731 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QhgWL-0008Jk-7l for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Jul 2011 07:25:25 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QhgW0-0008IN-KH for bug-gnu-emacs@gnu.org; Fri, 15 Jul 2011 07:25:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QhgVz-0006Mk-78 for bug-gnu-emacs@gnu.org; Fri, 15 Jul 2011 07:25:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39200) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QhgVy-0006Mf-Ra for bug-gnu-emacs@gnu.org; Fri, 15 Jul 2011 07:25:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QhgVx-00050O-QS; Fri, 15 Jul 2011 07:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Jul 2011 11:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5293 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 5293-submit@debbugs.gnu.org id=B5293.131072909019223 (code B ref 5293); Fri, 15 Jul 2011 11:25:01 +0000 Original-Received: (at 5293) by debbugs.gnu.org; 15 Jul 2011 11:24:50 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhgVm-000500-5u for submit@debbugs.gnu.org; Fri, 15 Jul 2011 07:24:50 -0400 Original-Received: from mail-pz0-f41.google.com ([209.85.210.41]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhgVj-0004zn-FM for 5293@debbugs.gnu.org; Fri, 15 Jul 2011 07:24:48 -0400 Original-Received: by pzk4 with SMTP id 4so1328658pzk.0 for <5293@debbugs.gnu.org>; Fri, 15 Jul 2011 04:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=GQuZnquTma6KApUzLs0Wy3zbZ1mMFAYW2iT66lvzL4Y=; b=EVaYEsCuBilez+ff95PSay+2ha3qxYttuOp5P6k8DZmpfik9LJhzENKVZziDzmJ7XM hABZhxcYWcK8KdiJbnfHTUiAq3g5eQL4Wm39fq8j7zA8drAQONBPIYMAQl0L50j9dybI Sy70PZZBr9VHwvw/pSB/amuH3l9auDeRFgufk= Original-Received: by 10.142.222.14 with SMTP id u14mr1431012wfg.309.1310729081370; Fri, 15 Jul 2011 04:24:41 -0700 (PDT) Original-Received: by 10.142.144.4 with HTTP; Fri, 15 Jul 2011 04:24:00 -0700 (PDT) In-Reply-To: <87oc0wdiy9.fsf@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 15 Jul 2011 07:25:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:49118 Archived-At: On Fri, Jul 15, 2011 at 10:52, =C5=A0t=C4=9Bp=C3=A1n N=C4=9Bmec wrote: > 1) If your reasoning about hooks being added via modes were correct, you > wouldn't have to remove even the global hook additions. Why? Global additions are not removed when the buffer's major mode is switched. Local variables, including local values of hooks, are. > If it's faulty > (which is probably the case), both global and local hooks need to be > managed, as Kevin said. I'm more of the opinion that both should be un-managed. A look at the sources is enough to see that hook removal is currently ugly and ad-hoc, and ugly too. > 2) The `unload-feature' docstring says it undoes "any additions that the > library has made to hook variables", but that's apparently not what's > really happening, so if things stay as they are, the doc string should > be corrected. Yes. The docstring for unload-feature has always promised more than it could reasonably accomplish. Yours is only one example. > 3) Are local hook additions really such a "hard/unstandard" thing to > undo? Local hook additions aren't. And they are correctly treated right now. What we are discussing is local hooks in buffers whose major mode wasn't also defined in the same feature being unloaded. For example, things like ;;; my-mode.el (define-derived-mode my-mode ...) (defun my-mode-this () ...) (defun my-mode-that () ...) (defun my-mode-hook () ...) (with-current-buffer (get-buffer "some poor unsuspecting buffer")) ;;; do not set the buffer major mode to my-mode, but (add-hook 'some-hook 'my-mode-hook nil t)) (provide 'my-mode) ;;;; end of my-mode.el and that kind of thing is unfrequent enough that the better fix is (defun my-mode-unload-function () (ignore-errors (with-current-buffer (get-buffer "some poor unsuspecting buffer") (remove-hook 'some-hook 'my-mode-hook t))) nil) Both Kevin and you seem to think that unload-feature should do everything and that having to define FEATURE-unload-function is a bug or something like that. It is not. I'm all for making unload-feature smarter, as long as it does not trample on the programmer's ability to do. I can perfectly well imagine unloading a package but setting a hook with an autoloading function from that same package. =C2=A0 =C2=A0 Juanma