Re: table.el

[Stefan Monnier]

>              ;; Hooks can also contain a non-list.
>              (unless (consp ,wrapper-var)
>                (setq ,wrapper-var (list ,wrapper-var)))
> 
> This feature exists for hooks only for historical compatibility.  We
> discourage its use.  There is no reason to support it for a new
> feature such as wrappers.

Great, let's scratch it then.

>     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,
> 
> The local/global handling is just a few lines of code.  Making a
> subroutine for that would cost more than it is worth.  It would make
> the code slower, and bigger, and more work to understand because not
> self-contained.

The advantage of a shared function comes in the case where we want to
extend the semantics of hooks (as in my example of locally removing
a function that's only present on the global part of the hook).

> 1. Define some new mechanism just for this purpose, and make it reliable.
> 
> 2. Pass a constructed lambda expression as Stefan(?) suggested.
> 
> 3. Establish a convention that the user should write the outside
> function name, quoted, as the second element of WRAPPER-FORM.
> 
> It is be useful to be able to test the function name, so I think 3 is best.

Yes, there's now a clear consensus on that, I believe.

>     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.
> 
> That is a strange thing to say.  Of course hooks are variables.
> They are variables used for a specific purpose.

Agreed, as long as you ignore the distinction between the
interface and the implementation.


        Stefan