Hooks enhancements (list all hooks)

[vindarel]

So hooks open up for many many cool stuff. Here's a meta issue on what can be improved to work with them.

• as a user/developer trying to extend Next in the REPL, I define hooks and suddenly I ask myself: "what did I just add"? We should have a way to list all existing hooks.
• some hooks expect a return value, my hook will break if my function accepts say a buffer instead of an url: compilation-time type warnings would help.
• when I break Next with a bad hook, I'd like a way to disable them altogether. For these two, see Hook class with toggler and handler types? scymtym/architecture.hooks#3
• currently, redefining a function that was added to a hook doesn't actually update the function of the hook. See Redefining a function does not update the handler scymtym/architecture.hooks#4
• add-to-default-list or (setf) get-default doesn't add the hook to existing objects, pushing to say (load-hook (active-buffer *interface*)) doesn't add it to the default list: an interface might help (with the double benefit that the user doesn't directly touch the internal data structures: its ini file is more resilient to future changes).
• add-to-default-list needs the class as argument: (add-to-default-list <hook> 'remote-interface 'buffer-make-hook), which the user cannot guess (it must be documented). Probably a wrapper can make it easier.

[Ambrevar]

If I'm not mistaken, the all the above is now merged on master except for the ability to list all hooks.

[jmercouris]

You are correct, ability to list all hooks is missing. However you can easily find the hooks in slime with completion by typing "next:" TAB and then searching for "hook" in the completions.

[aartaka]

Closing this. I'm pretty sure our describe-any/describe-slot can handle that, especially given that all the hooks have a -hook suffix in their names.

To implement hook listing as a command/function, one'd need to go through all the slots and variables and find those that are nhooks:hook-typed, which not all of the hooks are (let alone the strictness of typing on different implementations). Listing instances of nhooks:hook and subclasses may be better, but the best approach to it would be non-portable at best (ﾉ´ｰ`)ﾉ

[Ambrevar]

There is another way: in the nhooks library we can tweak the initializer to references all the hooks, which would then be reported by a nhooks:all-hooks functions or the like.

But this does not report the bound symbols, if any.
@aartaka's approach does it however.

Do we want both approaches?

This is a fairly general problem in CL, others must have dealt with it before, nah?

Issue opened at atlas-engineer/nhooks#14.

[aartaka]

Huh, registering hook instances can be a good way there, because then we can check the symbols we find for being bound to these instance!