Fork me on GitHub

@solicode: @grav: @darwin: I’m actually not sure about the interaction of those flags with values returned from the REPL. It will depend on the type of REPL you’re using. A clojure.main REPL just spits everything to stdout, so they should take effect there.


nREPL is more complicated - IIRC (but I’d have to check), values are pr-str’ed on the nREPL server to be passed back to the client. The values will possibly be truncated at that point, but I’m not sure - the thread bindings are tricky, I’d have to look at the nREPL source to be sure.


Once the nREPL result is back on the client, Cursive will just print the whole thing and ignore those flags. The flags are set on the REPL server anyway, not the client side so Cursive can’t even see them at that point.


I think having some config in Cursive to replicate them is probably the best solution, assuming the flags are not obeyed before passing the data back from the server.


Thanks for the explanation @cfleming. I looked at pr-str and it does seem to respect *print-length* and *print-level*. It looks like everything might is fine. Now I'm wondering if I accidentally had set *print-level* instead of *print-length* when I was testing with Cursive and came to the wrong conclusion. Sorry about that.


@solicode: No worries, like I say I’d have to look at the code to be sure, it’s been a while. I’m quite prepared to believe there’s a problem there - several people have reported problems printing huge data structures, but perhaps they hadn’t set those variables.


I’ll take a look when I get a moment.


pr-str is definitely subject of those *print-something* settings, as @cfleming correctly pointed out nREPL uses pr-str on the nREPL-server side and send just a string over the wire. In case of local REPL, someone has to call pr-str or similar function which boils down to standard clojure printing machinery, because the outputs are properly formatted. The question is who does it and what clojure runtime environment is present around that call.


Unfortunately during Dirac development, I found out that whole REPL, nREPL and piggieback stuff is written in a style in which it is extremely hard to read and reason about for me, I’m not that much experienced in Clojure, but I think that after one year of pretty intensive Clojure work, one should be able to read any code. This is not the case. I can understand just local pieces of it, but not the whole picture.


@darwin: Yeah, the nREPL code is very complex, and a lot of the REPL infrastructure code is complex and hard to understand too.


I’m going to add proper CLJS REPL support soon, so I’ll be fighting that battle again. Still, taking nREPL and piggieback out of the loop will be a huge win.


@cfleming: maybe we should cooperate with that CLJS REPL a bit, because hopefully soon I’m going to implement “echoing REPL support for Dirac in Cursive”. I want to be able to use DevTools console as output window and be able to send forms from my Cursive session to it


for this I believe I won’t need support from Cursive, I will just run my nREPL server, with some special middleware, which will additionally “send" forms to Dirac


in other words for Cursive it will behave like standard nREPL


Hi, has anyone here worked out a configuration to make Cursive and IdeaVim play more nicely together? I checked and found that it is possible to map som Cursive actions to vim binding, but I am not quite sure about how to begin