Use of (in-ns) evals on BufEnter in nrepl connections

[pinealan]

By my uneducated guessed, the evaluation of (in-ns <name-space>)on the BufEnter hook is necessary for connections to socket repls to provide a smooth experience for when user initiated eval commands are triggered. However is it necessary for nREPL connections too?

With nREPL, it seems an :ns parameter can accompany the :eval op achieve the same development experience without flooding the repl with evaluations of (in-ns).

My motivation for raising this issue is that the in-ns evals are messing with other nREPL tools, reveal in particular in my usecase.

I believe a naive implementation would be to

1. Add :ns key to the op map in iced#nrepl#eval#code using iced#nrepl#ns#name_by_buf
2. Remove the call to iced#nrepl#ns#in in iced#nrepl#auto#bufenter

Does anyone else have the same issue? Would this change break other workflows? What would be a better way to do this?

[liquidz]

@pinealan Thanks for your suggestion!

I've tried to use ns parameter, and I got a problem with figwheel-main.
#225 (comment)

But I only checked it a year ago, so we should check it again.

[liquidz]

@pinealan Sorry for late action.

I re-enabled using ns parameter in eval-ns-parameter-again branch, and it seems working well for me in normal nREPL, shadow-cljs, and figwheel-main.
In this branch, vim-iced does not use in-ns, so could you try eval-ns-parameter-again branch?

[liquidz]

@pinealan Hi! If you have a time, could you try eval-ns-parameter-again branch?

[pinealan]

@liquidz sorry for the delay and thanks for the update! The branch works perfectly for me on Vimr 0.35 + Neovim 0.5.1 + nREPL 0.8.3 on both JVM clojure and figwheel-main.

[liquidz]

@pinealan Thanks for your confirmation!

[liquidz]

@pinealan Just released v3.7.4 #380