piggieback only captures a distinct set of bindings when it starts up
bhauman opened this issue · 3 comments
It would be great to capture and restore all the bindings but that would cause a nightmare for all the nREPL and other middleware bindings that are present. This now makes me think that all nREPL middleware bindings should be scoped to a single binding holding a map and/or an atom so that they are distinct from the real bindings when you launch something like piggieback. Then piggieback could simply capture all the bindings on cljs-repl start and restore when a message comes in.
Another simpler solution would be a way of explicitly add bindings to the environment when we start the cljs-repl. We could do this with a binding piggiback/*extra-bindings* {'figwheel.main/*config* {}}
Hi Bruce, do you mean trying to find all the bindings in cider-nrepl and group them, a bit of a grunt work but I might have time for that.
At any rate - I see most issues are for some missing bindings so we definitely need some way to get a handle of them.
If my client reconnects to the server and reuses the piggieback session I end up losing stdout. I've also found that the "out" messages I get from evals such as (println "foo") don't have the correct message ID associated with them. The return value and all other messages do though.
Maybe it's related to this issue? This behaviour could be a clue that points towards the root cause?