Use lower nREPL print quotas for interactive evaluation

[vemv]

Fixes https://github.com/clojure-emacs/cider/issues/3633

Seems to work nicely (per the nrepl logs, and evaluating some huge objects).

Marking the PR as draft as I'll want to test out the defuns one by one.

Although many are affected, a good variety of defuns are unchanged - we still use the larger quota for repls, stacktraces, logs, tests, etc - basically whenever the nREPL output is printed to a buffer (vs. to an overlay).

I based the quota size on the frame, as definitionally one cannot display an overlay larger than the current frame.

Cheers - V

[bbatsov]

Let me think about this one for a while. I get your point, but I'm wondering if that's the right solution to the problem - this quota exists mostly to avoid out of memory errors on the nREPL server side, for limiting printing there might be other options we can consider.

[vemv]

this quota exists mostly to avoid out of memory errors on the nREPL server sid

TIL tbh!

I quite often see the limit trimming the REPL output, so I thought that was big part of its reason to exist. Or at least it's a fortunate side-effect.

[bbatsov]

I couple of general concerns?

• How will the trimmed results look exactly? (both in the minibuffer and in the overlay) I believe we use the same handler for both, so at the very least it should be clear that something got trimmed and what caused this to happen.
• By trimming results at the nREPL level it won't be possible for people to request the full result to be rendered
• I'm not sure if the interactive results are streamed (I think not, even if we discussed it with @yuhan0 in the past, if I remember correctly), so perhaps we can make the streamable and if the first chunk is full we can just assume something is relatively big and display it in a buffer instead of an overlay.

I'm also wondering how big of a problem is this in practice as people have rarely complained about it.

[bbatsov]

Ping :-)

[cichli]

FWIW: when I added the default quota we didn't even have the evaluation result overlays! I think a smaller quota definitely makes sense there (and perhaps anywhere we insert into the current buffer) but the larger one still makes sense for cider--pprint-eval-form since it outputs to a popup buffer. In fact if I know an eval output will be large I prefer to use a popup buffer over the REPL. I realise that breaks the "interactive eval" distinction though.

this quota exists mostly to avoid out of memory errors on the nREPL server side

Streamed printing solved that (for well-behaved pretty printers like fipp) but adding the quota was also to prevent the server overwhelming the client – it used to be easy to cause emacs to lock up by accidentally evaluating a huge data structure e.g. CLJS compiler state or an infinite seq.