Add wait-on-handler.

[Ambrevar]

@aartaka What do you think?

I haven't tested it though.

[aartaka]

I always thought of hypothetical wait-on-handler as something that has no body and is merely a function/function-like macro:

(progn
 (wait-on-handler the-hook)
 (do-something-now-that-the-hook-has-fired))

So I somewhy thought of it like prompter:all-ready-p, not like on.

In this implementation, I don't see much value but blocking the hook, which is trivial in most of our use-cases already. Even if wait-on-handler may be used without the body at all, this &body is still quite misleading. I'm hesitant about accepting this implementation until seeing its immediate usefulness.

(I feel like exceedingly/wrongly picky...)

@Ambrevar, I guess the question resolving my doubts would be: how do you plan on using wait-on-handler, syntactically and semantically?

---

On a separate note, we've always discussed it as wait-on-hook or wait-on-handler, but what about a shorter and more consistent wait-on? Is that overly vague? I like it (:

[Ambrevar]

I always thought of hypothetical wait-on-handler as something that has no body and is merely a function/function-like macro:

This looks like procedural programming ;) The benefit of having a body is that it makes the whole thing more functional since you can't proceed in the wrong order.

To clarify in case you forgot, you were the one who asked to move this macro to nhooks in the first place, so you must have found it useful at some point ;)

I'm fine with wait-on ;)

[aartaka]

I always thought of hypothetical wait-on-handler as something that has no body and is merely a function/function-like macro:

This looks like procedural programming ;) The benefit of having a body is that it makes the whole thing more functional since you can't proceed in the wrong order.

Yes, fair point. Won't hurt having this unambiguous order of evaluation, yes.

To clarify in case you forgot, you were the one who asked to move this macro to nhooks in the first place, so you must have found it useful at some point ;)

Yes, I did, but I somewhy remembered it to be this procedural thing. Anyway, I've not more complaints to this PR, so feel free to merge (after renaming to wait-on, I guess) :)

[Ambrevar]

Actually there is a conceptual problem here: we cannot wait until the hook finishes running all handlers, because it depends on the combination type. So attaching a handler last will not ensure that it is run last, could very well be run first.

So if we can't wait on the hook to finish, we can at least wait on it until it fires.

[aartaka]

Cool, thanks!