Re: remove-hook.

[Lute Kamstra <Lute.Kamstra@cwi.nl>]

Stefan Monnier <monnier@IRO.UMontreal.CA> 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.