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

[Daniel Mendler <mail@daniel-mendler.de>]

On 5/2/21 11:09 AM, Lars Ingebrigtsen wrote:> 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.

I understand. This argument is pretty similar to Drew's argument, but
realistic. The problem is that people expect idempotence when evaluating
their ".emacs". This property breaks as soon as we require `eq` and if
we want to retain this behavior we have no alternative than keeping the
current behavior.

From my experience, relying on this accidental idempotence when
evaluating buffers almost ever breaks in more intricate scenarios, so I
am usually not relying on this behavior. But making it break more often
is not a good idea, in particular in this important use case of the
".emacs", which is one of the points where people get first contact with
Elisp.

There are the following resolutions from my perspective:

1. Do almost nothing, but document the behavior of `add/remove-hook`
more precisely. Add a warning, that the functions should not be used
with large/cyclic closures and an symbol indirection should be used in
such scenarios. Generally it should be recommended to add symbols.
2. As you propose we could either add new `add/remove-hook-eq` variants.
3. Add an argument to the `add/remove-hook` functions, which allows to
turn on `eq` equality.

I assume the problem is mostly gone now due to the patches applied
previously by Stefan to `add/remove-hook`, which removed the depth
information to avoid leaks. In particular the problem with the original
`minibuffer-with-setup-hook` I observed was gone after the changes to
`add/remove-hook`. So my favorite resolution is 1.

Daniel