@mauricio.szabo It's not part of the protocol per-se, so it's hard to query about it. Right now you can check for ops, but not for their supported params.

That being said - CIDER supports it, hopefully Calva as well. //cc @pez You can easily check if an editor supports it by checking the message exchange between the editor and nREPL.

How does it work? Calva doesn’t support it, but I’d be happy to make it.

@pez it's quite simple, you just pass :nrepl.middleware.print/stream? 1 for the nREPL eval op and then "big" results will be returned in batches

I'm thinking about supporting it on my new version of Chlorine. The "hard" part is that Chlorine interprets the result (and does not capture it as a string); I made a encoder/decoder based on bencode, but for EDN objects, I want to now try and make it compatible with nREPL stream (by being compatible meaning, make it a lazy list of fragments and let nREPL do its magic and batch specific elements)

What are some situations when it matters?

@pez you mean, when it's actually useful to return the result as batches?

Yes, I haven’t exactly missed it in my own use of the repl.

Well, when I evaluate something quite big, or infinite lists, for example, that could be useful

Probably you haven't missed because you're capturing the result as strings. I am interpreting the result and converting back to EDN, in some cases this generates a big structure (when debugging Lacinia, for example) and it sometimes I can measure the parsing time in seconds (which is not a good experience, because then I have to render that structure :rolling_on_the_floor_laughing:)

With the idea I'm having now, I might be able to "partially parse" something that becomes too big

(BTW, @pez, everything I'm doing regarding this partial parse, the serialization, etc is completely separated from Chlorine and it's on its own repository if you want to know more about it 🙂 )

I’d be happy to have look!

I’d like to see that too!