Allow for extensible responses using monroe-custom-handlers. #11
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It did some magic in the past with different arguments, but I removed it since it required lexical binding, which is available since Emacs 24. I kept it for future expansion, if necessary... Do you have example of custom responses you are using with this patch? |
|
Do you have example of custom responses you are using with this patch?
Yeah, I am embedding an nREPL server in my game: https://technomancy.itch.io/bussard
You can connect to the in-game repl using monroe, but I have the game
sending periodic status updates out to all connected clients, and I want
Emacs to be able to update a status buffer when it receives these.
I understand this does not really further the original goals of Monroe;
however, the nREPL protocol is designed to be extensible even if current
tools tend to ignore this fact, and there is a ton of potential for new
interaction patterns that support for custom ops could enable.
I wrote about some of my ideas for ways that extensions to nREPL could
allow for exciting new developments here: http://p.hagelb.org/clojurewest-2014.org.html
|
|
Here's an example of client code that uses custom handlers: https://gitlab.com/technomancy/bussard/blob/master/bussard.el |
|
Cool idea and cool game project! The main reason I asked for this is to, at some point, update documentation with real example. Also, I really like the idea to make it extensible for custom nREPL commands :) Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I would like to allow custom handlers for a given op; this patch shows one simple way that could be implemented.
One thing I don't understand about the current implementation is why
monroe-make-response-handlerexists since it always returns the exact same lambda. Why not just make that a top-level function and dispatch all incoming messages to it? Then we could check for custom ops inside that function instead.However, this patch takes the approach that is least invasive and just falls back to a table of custom handlers if the ID is not found in
monroe-requests.