Use lower nREPL print quotas for interactive evaluation #3635
Conversation
|
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. |
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. |
| (let ((cider-print-quota (cider--make-interactive-quota))) | ||
| (cider--nrepl-pr-request-map))) | ||
|
|
||
| (defun cider--nrepl-interactive-print-request-map (&optional right-margin) |
There was a problem hiding this comment.
Maybe you should use the naming print and pprint in both helpers, as I find the current names confusing.
There was a problem hiding this comment.
And change cider--nrepl-pr-request-map's name to match.
There was a problem hiding this comment.
The pr one is so-named because it always uses clojure.core/pr, regardless of your printing options. The print one uses whatever your cider-print-fn is set to (which might also be pr, and so will not necessarily pretty print).
| \(repls, logs, stacktraces, tests, etc), | ||
| because by definition large values don't fit in the screen | ||
| and can slow down performance." | ||
| (min (max (round (* (frame-width) (frame-height) 1.5)) |
There was a problem hiding this comment.
I'm struggling to understand the logic of those calculations.
|
I couple of general concerns?
I'm also wondering how big of a problem is this in practice as people have rarely complained about it. |
| @@ -411,6 +411,34 @@ is included in the request if non-nil." | |||
| (when cider-print-quota | |||
| `(("nrepl.middleware.print/quota" ,cider-print-quota)))))) | |||
|
|
|||
| (defun cider--make-interactive-quota () | |||
There was a problem hiding this comment.
I'd probably name this cider--calculate-interactive-print-quota.
|
Ping :-) |
|
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
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. |
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