Clojurians Log v2

as the author of Enrich, I can say that moving away seems the right course of action for the simple reason that it's no longer maintained. I'm happy that it helped solve a problem that was deemed too hard before. And if we have something leaner now, so much the better!

Why is it better? is there a quick description of the difference?

https://metaredux.com/posts/2025/01/17/a-simpler-way-to-deal-with-java-sources-in-cider.html

thanks ill give it a read.

This was removed together with big nREPL refactor which also dropped the sideloading capabilities, unfortunately. I'd say that it wasn't deemed not useful, but rather the implementation was too complicated for the limited usability that it provided. But we may explore the possibility of bringing it back via simpler mechanisms in the future. Could you please tell what is your usecase for it? Do you start nrepl server without cider-nrepl and then want to sideload cider-nrepl middleware into it? Is there something that prevents you from including cider-nrepl at the server side?

We had been including it in our project dependencies because half our team uses cider, but the other half does not. But after the bug last week that maxed out 100% CPU for the colleagues that did not use cider, it was decided that dependency had to be removed and we were left to figure out how to include it if we need it.

Damn, that's unfortunate. By the way, the 100% bug is fixed now (should be, at least). What do you use for your project, tools.deps?

Yes, so we’re looking into user.clj to load it, but I have to stop the integrant wrapped nrepl service and restart it with cider nrepl loaded and enabled instead.

Wait, is it for a case for a remote REPL or is it run locally?

Locally, but would still like to repl into prod sometimes. I can live with reduced functionality in remote prod

Nrepl alone on prod might be enough

I mean, for local case you can include the cider stuff in a separate alias and conditionally enable it, right?

Yes I’m working on that now. It’s just a nuisance lol

I guess, you would need to hack the nrepl starting code too. I assume, you don't use cider-jack-in, but the nrepl server is started manually from the code?

Since nrepl will remain, side loading would have been nice but not essential

Correct, I prefer to start it and then connect. My colleague uses jack in however

With jack-in it's all done automatically anyway. If you start and connect, then it's common to make a separate alias for it. It's pretty much a common approach and a better one than including cider-nrepl into project dependencies (unless you also want cider-nrepl in prod but that's another story, yeah).

Well, then I’ll be learning a superior approach it seems.

I always started and then connect separately. Is there any advantage to starting it directly from emacs?

Benefits of starting separately: • You have the REPL process in a dedicated terminal, see that it is running, can kill on demand. • Restarting Emacs leaves your REPL env intact. You can restart Emacs and reconnect to the same REPL. Benefits of cider-jack-in: • Puts all the necessary dependencies and config for you, so you don't need to have in-project or system-wide configuration for it in profiles.clj or deps.edn files.

I asked this question before and there weren't many Puget users based on the answers: https://clojurians.slack.com/archives/C0617A8PQ/p1740567500814809

Thanks. Yeah, a lot of options, for some reason i was using pudget and i think it's been removed from nrepl so i have to include it or change to something that is included. I guess i'm confused on how these things compare. Like which one did nprel keep? pudget (obviously not) fipp, zprint? I probably didn't even need puget, it looks like it just adds things that matter if you print to the repl, which i don't do, i just use it in emacs. That and "Canonical Representation" which i would need rarely...

pprint to use the built-in clojure.pprint/pprint (this is the default). That makes sense.

I agree that CIDER includes too many pretty-printers, the difference between them is quite minimal, and it mosly only matters for stuff that is printed into the REPL buffer. That's why we've started to remove some of them. Zprint was never included, Puget is gone now, and Fipp is going away next. All three are still supported but you need them in the dependencies explicitly. I'd say 95% people either don't need pretty-printing in the REPL buffer (there are better tools for exploring data in CIDER, like https://docs.cider.mx/cider/debugging/inspector.html), or regular clojure.pprint/pprint is enough for them.

Will that affect formatting of output in *cider-result*?

i prefer fipp for basically this one reason (and its faster)

card=> (fipp.edn/pprint (into-array [1 2]))
#object["[Ljava.lang.Long;" "0x7e55e9fe" "[Ljava.lang.Long;@7e55e9fe"]
nil
card=> (clojure.pprint/pprint (into-array [1 2]))
[1, 2]
nil

arrays printing as vectors can be misleading when you don’t want it. or enormous

> Will that affect formatting of output in *cider-result*? Yeah, right, that one too.

Well that's a bummer

What particularly, @daveliepmann? The puget thing?

I suspect most people who use that feature use it because of the pretty-printing

I'm responding to "95% people either don't need pretty-printing in the REPL buffer (there are better tools for exploring data in CIDER, like inspector)". I don't want to use the inspector, I want pretty-printing in *cider-result*. I don't have a clear idea of how the *cider-result* buffer will change but if it's a small difference between puget/etc and pprint then I don't see a problem

(Adding a config step only bothers me when I put on my beginner-advocacy hat)

This was me responding to @drewverlee who is rightfully confused about the abundance of pretty-printing options and which should he choose and if it matters. From that standpoint, this is indeed not worth the added mental resource.

None of the existing pretty-printers are going away from CIDER. What changes is that in order to use one, you would need to put it onto the classpath explicitly. Or as an alternative: • Select the regular clojure.pprint/pprint • We actually added another pprinter recently (I know facepalm) https://github.com/clojure-emacs/orchard/blob/master/src/orchard/pp.clj. It is based on https://github.com/eerohele/pp. It will probably be added as another printing option in CIDER in the future, and it will also be used as a fallback default for when Fipp/Puget/Zprint is selected but can't be found on the classpath.

Thank you for the explanation 🙏

I think I misunderstood

It is confusing alright

I’m just going with (cider-repl-init-code . ("(set! *print-namespace-maps* false)")) for now

so I have

(setq cider-print-fn 'pprint)
(setq cider-print-options '(("print-namespace-maps" nil)))

which doesn’t work because cider.nrepl.pprint/pprint doesn’t do the with-bindings which only cider.nrepl.pprintp/pr does: https://github.com/clojure-emacs/cider-nrepl/blob/6e0d8421bebc87d047dee16dccc04331af8e7e5a/src/cider/nrepl/pprint.clj#L50-L55

however, even if cider.nrepl.pprint/pprint would use (with-bindings (pr-bindings options) ,,,) the nil from the cider-print-options is encoded as [] as the options are parsed as {:print-namespace-maps []} so that also is not helpful…

I found https://github.com/clojure-emacs/cider-nrepl/issues/807

and this seems to be related to encoding nil : https://github.com/clojure-emacs/cider/issues/2362

so for now I go with a custom cider-print-fnwhich rebinds #'clojure.core/*print-namespace-maps* regardless of the options. but I’m wondering if I’m missing something?