Add result type :return to custom eval#11
Add result type :return to custom eval#11ibdknox merged 3 commits intoLightTable:masterfrom tapeinosyne:result.return
Conversation
Allows asynchronous programmatic access to the result of a custom eval. A custom evaller must pass an option map containing `:result-type :return` and a `:handler object/object` that listens for a `:return` trigger; upon successful eval of the custom function, its returned value is sent to the triggered behavior.
Custom evallers of `:result-type :return` can include a `:trigger` keyword in their options map to specify the trigger to raise upon successful completion. The default trigger is `:return`. The data sent to the handler is now a map containing: `:result` as the eval result, and `:loc` as the location of the cursor at eval invoke time.
|
I have added custom triggers, and results are now passed as a map also including cursor data. |
|
This looks quite useful to me. I've been thinking of using LT in a fashion similar to this project for a while, and without digging into it too much it'd strike me as this feature would be helpful in implementing it: https://groups.google.com/forum/#!topic/clojure/Olc9kznvnTw |
|
Maybe we should just merge opts into meta. |
|
Good point. By the way, @ibdknox, I noticed that you bumped the Clojure plugin to 0.10 in the repo without adding new releases. Oversight? |
Allows to add arbitrary options to a custom evaller. If `result-type` of the evaller is `:return`, the full map of metadata is returned instead of just the cursor location. The data sent to a return handler is now a map containing: `:result` as the eval result, and `:meta` as the metadata used for custom evaluation.
|
Yeah, oversight. I was trying to push up a fix for Sean Corfield but didn't really want to release it until he could verify. |
Add result type :return to custom eval
3 participants
A new :result-type for custom evallers that allows to pass the evaluation's result to an arbitrary object instead of displaying it. (For those familiar with Clojure development on Emacs, this would be analogous to CIDER's eval-and-get-value, with the additional benefit of being async.)
Such a facility would be rather useful for plugin development. It grants the caller easy programmatic access to the result of a custom eval, allowing them to behave accordingly.
For example, a factoring command could listen for the result of an analysis, then use its value to produce a snippet and move the cursor to the most convenient position in the editor.
This first implementation enforces a one-to-one correspondence between handlers and behaviors, because a custom evaller of type :return always raises the same trigger. An immediate improvement that I think rather desirable would be to allow the caller to also specify which trigger to raise upon successful eval, so that a single object may manage multiple events. (Edit: this improvement is now in to the branch.)
Here is a simple test case for this PR. If you are interested, I will extend the patch with the addition mentioned above and a few other things (such as returning the location, which is currently unused) before merging.