Re: table.el

[Tak Ota]

Mon, 03 Dec 2001 00:26:39 -0500: "Stefan Monnier" <monnier+gnu/address@hidden> 
wrote:

> And?  What's the problem with that?  All we want is a function, right?

As you wrote before it is useful sharing one hook function to handle
several cases based on the received function.  For this purpose it is
much easier receiving the symbol rather than lambda expression, which
is not obvious what function it is.  Sure, there is no problem for
calling it.

> >   "Invoke wrappers in WRAPPERS-VAR if present, otherwise execute forms in 
> > BODY.
> 
> As I said WRAPPER-VAR is a misnomer since hooks just aren't variables.
> They are represented as symbols (just like coding-systems, faces and
> several other kinds of objects) and they happen to use the `symbol-value'
> and the `default-value' of a symbol for their internals which makes
> them look similar to variables, but they are not variables.

Sorry, it started that way and I forgot to change that part.

> >        ;; Call the first wrapper, with function and args.
> >            (funcall (pop ,wrapper-var)
> >                 (nth 1 (backtrace-frame
> >                         (if (eq (nth 1 (eval-when-compile (backtrace-frame 
> > 1))) 'progn) 7 1)))
> 
> The problem here is not just that this is brittle, but that
> it breaks as soon as you do
> 
>       (defun foo ()
>         (let ((bli sdf))
>           (with-wrapper-hook (foobar arg)
>             ...)))
> 
> I think it's just fundamentally wrong to use `backtrace-frame'
> because we can't and don't want to rely on the fact that the
> `with-wrapper-hook' is the first thing in the function's body.

I implicitly made an assumption that `with-wrapper-hook' was the
first, or next to interactive, in the function definition because
otherwise it defeats its purpose since anything before
`with-wrapper-hook' cannot be wrapped.

BTW, as I wrote above I found a minor flaw in my approach.  When the
original function has some operation in interactive body, that
operation can not be wrapped.  I suppose this limitation is not fatal
but is something that we must be aware of.

> But I now think it's better to keep things simple and not pass
> the function at all.  Or rather, if the function is needed,
> just pass it explicitly:
> 
>       (defun kill-region (beg end)
>         "bla"
>         (interactive "r")
>         (with-wrapper-hook (region-wrapper-hook 'kill-region beg end)
>           ...))

I think this is the most elegant solution!

BTW, RMS said the hook is better be hooks in this case.  Also the
emacs lisp manual says when the hook takes arguments they are called
hooks instead of hook.  So lets rename `with-wrapper-hook' to
`with-wrapper-hooks' and `region-wrapper-hook' to be
`region-wrapper-hooks'.

> I'd still like to find a way to reuse `run-hooks' rather than
> manually handle the non-list-to-list conversion and the local/global
> thingy, especially since my hidden agenda is to add support
> to run-hooks for negation so that I can buffer-locally remove
> a function that was added globally to the hook:
> 
>       (add-hook 'foo-hook 'bar)
>       (remove-hook 'foo-hook 'bar t)
>       (list (default-value 'foo-hook) foo-hook)
>       ((bar) ((not bar) t))

I'm looking forward to your effort in this area since I am not very
familiar with that.

-Tak