Fork me on GitHub
#cider
<
2023-10-15
>
Carsten Behring09:10:52

I was lately tinkering a lot using alternative value inspectors in CIDER, such as Clerk and Portal. One "generic" way to integrate them a bit closer into a CIDER based workflow, is to enable "automatic tapping of CIDER evaluation results. And then configuring Portal or Clerk to show all tapped results in a browser. This will then result in seeing all evaluation results in a Browser. At least for Clerk's tap-inspector this works well as it deals well with (and folds) long results automatically. This can be done rather easily already today, by advising cider-nrepl-request:eval (Thanks to @daslu for initial code snippet)

(defun clojure-tap (&rest r)
  (cons (concat "(let [__value "
                (caar r)
                "] (tap> __value) __value)")
        (cdar r)))

(defun cider-nrepl-enable-auto-tap ()
    (interactive)
    (advice-add 'cider-nrepl-request:eval
                :filter-args #'clojure-tap))
Should this become functionality of CIDER itself, as being generic ?

vemv10:10:20

https://github.com/clojure-emacs/cider/issues/3055#issuecomment-1736099756 is the approach I intend to get into cider, as far as tapping is concerned I'd be wary of tapping everything. While it doesn't sound disastrous, it's also not the sort of thing that we should officially foster

Carsten Behring10:10:12

fine for me. Users can do it on "own risk"

👍 1
Carsten Behring11:10:23

I read over the discussions, and can now give my comment here, more about my "request". One question is if / if not CIDER should have "support" for easely "tapping" everything. In my view this is a yes/no question, no further config. Either it "taps" nothing "on evaluation", as now. Or it allows easely to "tap everything". This has indeed a certain "risk" of exploding memory, so fore sure should be disabled by default. It is of course already "easy", as my snippet shows. The second question is, if CIDER should make it more easy to add tap handlers, and if / if not something should happen automatically when epl starts. Maybe it helps as well to think about my initial use case, which is to "keep a visual list of all past evaluations results", which CIDER does not have at all as feature. (+ it allows me to have that list rendered in Browser, so having richt output)

Carsten Behring11:10:55

CIDER supports this in some form, but only of the last three results, just as Clojure does.

practicalli-johnny11:10:35

Having an option in cider that sends nrepl eval results to any registered tap source could simplify tool uses, although it seems the main tap tools already support nrepl evals. Portal data inspector works very well when tapping via nrepl middleware, automatically sending all evaluation results to Portal and keeping a full history ( Portal clear command will remove history if required) https://cljdoc.org/d/djblue/portal/0.37.1/doc/guides/nrepl I also send mulog log event message to Portal with a custom mulog event publisher that taps every log event. I enable this configuration and launch portal via a https://practical.li/clojure/data-inspector/portal/#editor-commands, so it can be selectively enabled when starting the repl.

Carsten Behring12:10:40

Indeed, middleware is an other option. I was searching once for a generic nrepl middleware which is simply "tapping" all results, but did not find any.

vemv13:10:43

It should be reasonably easy to implement a custom piece of middleware and add it to your stack This also may answer your second question - given a smart enough piece of nREPL middleware, it could be configured to satisfy diverse needs easily.

vemv16:10:11

ℹī¸ We've released cider-nrepl 0.40.0 which fixes a subtle but generalized issue with macro metadata under ClojureScript. It's included in CIDER 1.8.2 / snapshot / master.

đŸ’¯ 3
daveliepmann17:10:14

Re: CIDER 1.8.x's https://github.com/clojure-emacs/cider/discussions/3338#discussioncomment-7285955, is it possible to get these short/non-stacktrace error messages as an overlay, without changing the *cider-error*-opening behavior of errors which involve stacktraces?

vemv17:10:37

Yes, we've worked specifically on it very recently Do you not see an overlay? It may be some setting, can check if you don't find it first :)

daveliepmann17:10:57

I only see messages in the minibuffer

vemv17:10:45

The logic for deciding whether an overlay is displayed is as follows:

(or
 ;; if we won't show *cider-error*, because of configuration, the overlay is adequate because it compensates for the lack of info in a compact manner:
 (not cider-show-error-buffer)
 (not (cider-connection-has-capability-p 'jvm-compilation-errors))
 ;; if we won't show *cider-error*, because of an ignored phase, the overlay is adequate:
 (and cider-show-error-buffer
      (member phase cider-clojure-compilation-error-phases)))

vemv17:10:26

And it looks like this:

daveliepmann17:10:03

I'm stumped. cider-version is 1.8.2 Geneva, cider-show-error-buffer is t (tho I also tried with nil), m-x : (cider-connection-has-capability-p 'jvm-compilation-errors) => nil. Yet I still see no overlay. i'm using cider-eval-last-sexp

vemv17:10:14

What about cider-eval-sexp-at-point ?

daveliepmann17:10:47

nvm, i got it — another part of my config was setting cider-use-overlays which I guess is also in the logic chain somewhere

vemv18:10:15

👍 . If you feel cider-use-overlays is too coarse-grained for your preferences, I'd be happy to discuss it over GH

👍 1