Yes, you can change this behaviour back to how it used to be. See https://calva.io/output/#repl-process-output-stdout-and-stderr Please let us know if that description makes sense to you. I hade a bit of struggle trying to describe it and don’t know how I fared.

Thanks, will have a look right away!

Makes sense to me, thanks for pointing it out. Going to turn it off 🙂

And it works like a charm.. much easier on the eyes haha

can you tweak your dev logger config instead? presumably “stuff” is logs that are needed in prod but obviously you wish to silence them in dev

Works fine and just like before with this new setting. No need to tweak dev logging as it runs as is 'production' but with dev data

Thanks for the tip tho

I think it's a common use case to want to keep logs turned up locally. Makes debugging easier. I much prefer the logs going to my terminal in std out instead of the repl window.

the java loggers (i.e. slf4j) have rich functionality for configuring where logs go, e.g. to a file or to a cloud log scooper

It’s a bit unfortunate with the lack of options for this. Either the user loses stdout from threaded evaluations or all stdout goes to the repl window. I’ve reasoned a bit around it on that issue, included that there is some little room for improving it, even if ultimately we’re at the mercy of what nrepl (and the repl) allows. Configuring your loggers is always an option, as Dustin suggests.

you can also intercept only clojure's *out* (println) but not the java stdout, i believe the calva patch intercepts both

the problem with that @U0ETXRFEW is shadow-cljs still logs the compiler results with println, which absolutely unequivocally must go to out which must be redirected to the repl. (I mention bc i know you prefer the old shadow behavior)

but java loggers in this case would go to terminal

I personally am okay with all my *out* or stdout going to my terminal (in my case it's side by side with my REPL window), but are we saying for ergonomics, we'd prefer println debugging stay in the REPL window, but everything else go to stdout including logs and such?

As a parallell stream we are also looking at challenging the repl/output window implementation and behaviour. This is great input, @U02GSTHEX3M. You can add to this issue, if you like: https://github.com/BetterThanTomorrow/calva/issues/1104

I'm starting to grasp the challenge you're facing. You can only override all of *out* ... not selectively override it. It's a bummer that's not better decoupled.

i.e. normal streams wouldn't be able to support metadata I don't think, so you couldn't really write a func that "chooses" where to send output

Well, you could selectively override it on a per REPL invocation basis, but within one invocation, you couldn't send i.e. all printlns to one stream and all logging library calls to another

We do have a hold that can separate messages stemming from evaluations from those coming from the server process for other reasons. At least it looks like that when examining the message logs. That’s the room for improvement on the structural level that I see. From there it’ll be a question of designing some good defaults and reasonable options without that getting to be a jungle of settings.

I'm not super familiar with nREPL's protocols / data formats so I'd have to read up on that to fully appreciate what you're saying. But I get the general idea.

I'll throw some commentary on the issues 👍

Basically it is something like so, afaiu: 1. nREPL structures requests and responses such as that we can know from which request a response stems (via the message ID) 2. By default it also sends back stderr and stdout from the request, tagged with the message ID, but only if it’s in the same thread 3. By default all other output slips through the nREPL server’s watch and the nREPL client never gets them 4. The nREPL server can be instructed to subscribe to stdout and stderr happening in the server process a. So instructed all stdout and stderr will be sent back to the client b. Output from child processes to the main evaluation thread seems to have the evaluation’s message ID c. All other output (I call them out-of-band) is tagged with the same message id (some early ID from the handshaking or something) 4a is the new default, and can be disabled in that setting. 4b and 4c is the room for structural improvement that I keep rambling about. Even if the 4b observation does not hold for all situations, it could still be worth leveraging. The latest issue I linked to suggests to open up for something like what you said you’d be fine with: Sending all stdout/stderr to some other place than the repl window. Then the repl window would be more purely about results exceptions. And users can arrange the repl window and the stdout/stderr view as they see fit.