From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lute Kamstra Newsgroups: gmane.emacs.devel Subject: Re: remove-hook. Date: Tue, 07 Oct 2003 17:13:02 +0200 Organization: CWI, Amsterdam Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1065539912 13116 80.91.224.253 (7 Oct 2003 15:18:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 7 Oct 2003 15:18:32 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Oct 07 17:18:30 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1A6tba-0007Av-00 for ; Tue, 07 Oct 2003 17:18:30 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1A6tbZ-0000PM-00 for ; Tue, 07 Oct 2003 17:18:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1A6tX4-0003ev-Rz for emacs-devel@quimby.gnus.org; Tue, 07 Oct 2003 11:13:50 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1A6tWt-0003ec-R1 for emacs-devel@gnu.org; Tue, 07 Oct 2003 11:13:39 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1A6tWN-0003TV-Hb for emacs-devel@gnu.org; Tue, 07 Oct 2003 11:13:38 -0400 Original-Received: from [192.16.191.8] (helo=hera.cwi.nl) by monty-python.gnu.org with esmtp (Exim 4.24) id 1A6tWN-0003TI-1I for emacs-devel@gnu.org; Tue, 07 Oct 2003 11:13:07 -0400 Original-Received: from occarina.pna.cwi.nl (occarina.pna.cwi.nl [192.16.184.200]) by hera.cwi.nl with ESMTP id h97FD5fA004161 for ; Tue, 7 Oct 2003 17:13:05 +0200 (MEST) Original-Received: (from lute@localhost) by occarina.pna.cwi.nl (8.12.8/8.12.5) id h97FD3b0009006; Tue, 7 Oct 2003 17:13:03 +0200 X-Authentication-Warning: occarina.pna.cwi.nl: lute set sender to Lute.Kamstra@cwi.nl using -f Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "07 Oct 2003 10:59:41 -0400") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) Original-Lines: 49 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:16985 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:16985 Stefan Monnier writes: >>> PS: Admittedly, this doesn't work in Emacs-CVS because the only way this >>> can work is if we can put "negative" entries on the local side of >>> a hook to disable an element on the global side. > >> If it doesn't work, the docstring is confusing. > > The docstring is still correct: if you pass the LOCAL flag and the hook has > no local side yet, `remove-hook' will create the local side of the hook. > It is a necessary first step for remove-hook to work. Admittedly, it's > currently a useless step because the necessary second step doesn't > work anyway. The docstring is not really correct as remove-hook also removes the buffer-local binding again: ... (if (equal hook-value '(t)) (kill-local-variable hook) ... >>> I have code to make it work, >> I'm curious... can I have a peek? > > Can't extract it right now, but it's pretty simple: > If there's no local `bar' element to remove, `remove-hook' adds a > (not bar) element. When `run-hooks' sees such a (not bar) entry, it > doesn't run anything, but stuffs `bar' in a list of hooks to inhibit > when processing the global side of the hook. And you still have the mechanism where t in the buffer-local value of a hook is substituted by the functions in the global value? >> I tend to agree that such a system would get rather complicated. >> It also seems necessary to keep remove-hook efficient: when I >> instrumented it, I noticed that it was called twice every >> keystroke. > > I don't see how that calls for efficiency. It's still tiny compared > to the time it takes for your keystroke to pass through the layers > and processing necessary for Emacs to get the event (and you can add > the time for Emacs to update its display, ...). I probably haven't developed a good intuition for these kind of speed things yet. :-( Lute.