Re: comint-carriage-motion causes severe problems.

[Stefan Monnier]

>     I would argue for the desirability of Stefan's suggested additions to
>     the hook machinery.  I believe they are absolutely necessary.  We have
>     right here a very good example why.
> 
> I think such a feature could be a good idea.  Stefan, could you state
> the proposed specs (don't worry about implementation at this point)
> for the feature?

The spec corresponding (barring bugs) to my current implementation
is as follows:

Among the list of functions specified in a hook, you can now have
one of the form (not . FOO) which says "if you come across FOO
in the rest of the list, just ignore it".

I.e. if the value of a hook is (a (not . b) c b), then `run-hooks'
will only run `a' and `c' but not `b'.  By "value of the hook" I mean
the combined local+global lists, so the above example could happen
in the case where the local value of the hook variable is
(a (not . b) c b) but could also happen if the local value is
(a (not . b) t) and the global value is (c b).

If you use remove-hook, add-hook, run-hooks, this new functionality
means that calling `remove-hook' will make sure that a subsequent
`run-hooks' will not run this code.
Actually, there are some unclear semantics when you do things like

        (add-hook 'foo 'bar)
        (add-hook 'foo 'bar nil 'local)
        (remove-hook 'foo 'bar 'local)

The current code removes `bar' from the local value of `foo' but
leaves it in the global one.  My new code does the same and only a second
(remove-hook 'foo 'bar 'local) will add a (not . bar) such that the
global setting is overridden.  This decision was arbitrary (mostly
trying to minimize the change in behavior for better compatibility).


        Stefan