Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Rewrite nrepl callback handling #1099
The lexical approach is awkward with respect to the composition of the handlers that @cichli proposed. So, I guess, this leaves us with the dynamic approach only.
I see at least two reasons for that.
Most importantly, this is useful for "global" handlers that CIDER or the USER can insert into the chain of handlers. Most common example is caching. As with
Secondly, if you don't bind the buffer automatically then the handler has to do that itself (all eval handlers for example). This means that you cannot simply define a callback and then store only its name in
I think the general idea is to store a complete context of the invocation and it's rather independent whether the handler wants to use it or not. For completeness I would also include the current point in this list (a marker actually). Examples are error handlers that must invoke a jump, and would like to push mark or xref-mark before hand. It might be useful for asyncronuous completion as well. Imagine asyncronous eldoc which would inhibit message display if the point moved in the meanwhile.
A more general idea would be to have
I know why it's done as it is. My problem is that there are plenty of handlers that just ignore the "attached" buffer and currently this isn't even an optional param.
Yeah, those are nice points. I have to spend more time thinking about this, but in the mean time - more ideas are welcome!
This is basically building middlware stacks each time you make a request. Seems rather cumbersome to me with no real gain. First, you have to read this backwards because the last one is executed first. From technical prospective, you store a huge lambda in the request cache. From a programer prospective it's rather inconvenient because of two competing concepts - handler and middleware that dynamically generates the handler (BTW,
How about a simpler linear dispatch a la
You can also compose handlers directly:
You can still use generators to dynamically produce closures that capture locals, but if we already capture the context (connection, buffer and point) this will be rarely needed.