Fork me on GitHub
Sergiusz Bleja12:07:47

I'm using the conjure dev shadow setup with the foo.cljs in the same repo. Run the ./ first and then started neovim. It seems like conjure assumes the n-repl connection is clojure. If I have the browser open on the page it sets it to clojurescript. Not sure whether this is default behaviour but it confused me quite a bit before I found a way around it.


This is a shadow + nREPL specific behavior, if there's no ClojureScript runtime connected (like a browser) then you're basically in Clojure land still. I may be misunderstanding here, but are you saying the order in which you boot things up / connect determines if it's going to work or not?


I tend to get shadow running my terminal, connect my browser, ensure it's all good and then connect Conjure when I know the nREPL server is all happy and connected.

👍 3

If you want to reconnect you could try ,sQ to kill all sessions and then reconnect with :ConjureShadowSelect app

Sergiusz Bleja14:07:57

Ok, thanks for clarifying - it makes sense. I think my mental model sort of missed that the browser is the runtime in this case.


Yup, it's conjure <-> shadow <-> browser, so if the browser isn't there, shadow has no CLJS. Shadow is the mediator between the browser's runtime and Conjure, Conjure never gets to talk to the browser directly. If that makes sense?

Sergiusz Bleja14:07:52

Yes, it does - nowhere to evaluate.


I know this isn't conjure related, but how would y'all recommend making a binding that calls one of your own functions on the result of an evaluation?


:thinking_face: you mean go and do an evaluation then call a function with the resulting string?


Because there's support inside Conjure to do this since all evaluations in practice are async. So it needs to be callback based.


I actually started writing up some docs for hooking into internal Conjure functions through Lua. This might be helpful




I've pushed some new functionality to develop that the previous generation of Conjure had: Resolving of file paths on eval to be relative to your CWD. This means that you can use <localleader>ef on files from your local disk while evaluating on a remote server or inside a docker container that doesn't share the same absolute path.


There's options to change the root it's resolved against in the case that your Neovim and JVM CWD are out of line as well as an option to turn this off entirely.


It shouldn't be noticeable for the most part, but if you regularly evaluate files within docker containers etc then it should just start working! (once it's released)


Another feature on develop! I've addressed with these options: So data structures will be elided past a certain length or depth automatically (as long as you have pretty printing enabled, which is on by default). This should save you from accidentally printing the universe, I hope.


Maybe the depth should be something more like 10-20. Any thoughts on these defaults (depth: 50, length: 500) is greatly appreciated!


You can set them to false to remove these limits when required, but most people won't have to ever worry about this, I hope.


I don't have any strong views on the defaults. Then again, I don't parse huge data structures atm 🙂


limiting by default sounds like a good idea to me!


as long as the limit is reasonably high that it doesn't feel like it will get in the way


and if it's configurable, that's even better