bug#47992: 27; 28; Phase out use of `equal` in `add-hook`, `remove-hook`

[Lars Ingebrigtsen <larsi@gnus.org>]

Daniel Mendler <mail@daniel-mendler.de> writes:

> It would be good to change `add/remove-hook` such that it only relies
> on `eq` to test hook equality. Then the symbol indirection workarounds
> can be avoided.
>
> However making such a change directly can lead to subtle
> breakage. Perhaps one could introduce some deprecation behavior first,
> before making the final change to `eq`.  If a hook is added/removed
> and the added/removed object is not found via `eq` but found via
> `equal`, show a deprecation warning?

There are two issues here:

1) Should `add/remove-hook' even attempt to do uniqueness checks when
adding/removing things that aren't symbols (or more generally, eq-able
things), and

2) Should `add-hook' disallow adding such things?

Today, it's super common for people to say

(add-hook 'some-hook (lambda () ...))

in their .emacs files.  This isn't because they have any expectation
that add-hook does this uniquely, or that remove-hook will work, but
because that's just what they think they should do.

So I think 2) is out of the question -- we can't deprecate this, and we
can't issue any warnings about doing it this way.  (Even if it's
"wrong" -- it's just not feasible to disallow this.)

And since 2) isn't possible, I don't really think 1) is possible
either.  People do `M-x eval-buffer' their .emacs files, and since we're
using `equal' here, this happens to work -- almost by accident.

(If they change the lambda, then they get two instances of the lambda in
the hook, so it's "wrong", but it's so common.)

So I'm not sure I see any way forward with this.  Would adding a new
pair of functions (that are `eq' only) help in any way?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no