Fork me on GitHub

I'm seeing a weird issue in that connecting to a remote nrepl I am subscribed to std out, even though I don't issue any such command -- and can't turn it off via :ConjureOutUnsubscribe. I'm seeing this only recently but I don't recall updating my nvim configuration or anything on the server.


Nothing changed around this recently :thinking_face: that out subscribe / unsubscribe thing is a thing in nREPL that I never found to do anything in practice. I'm sure it does something, I'm just not sure what. What you'll find is if a process / thread is started by your nREPL stdout will go to the nREPL buffer. If you start it in the code before you're connected then stdout will go to the terminal the REPL is running in. This has something to do with the printer nREPL internally binds I think... I'm not sure if there's a way to override that :thinking_face:


I'm not deliberately trying to capture stdout, but there may be a way to redef the printer as the one from the outer most context and not the one nREPL is passing in... this is complete guesswork right now 😬


Ah perhaps I’ve connected to that REPL very early and now nrepl has bound the printer?


I usually connect when it’s been running for some time


What could be the reason for Conjure to use a no longer active nrepl port when connecting? .shadow-cljs/nrepl.port has the right port number but the one used by conjure is different.


Is there a .nrepl-port file in your current directory or above?


Because it prioritises nearby .nrepl-port files over the shadow one at the moment. I have a todo to make it prefer the shadow one from cljs buffers, but not sure when I'll do that


There’s no .nrepl-port file in my current working dir


What about ~?


I've added a change to develop so you'll see what portfile was used for an auto connection (if at all)


~/.nrepl-port was the culprit! I had no idea that would be considered 😄


Yay! Yeah it walks upwards so a repl running in the root of your project will be caught even if you open nvim lower