C-c M-n should act on both repls in cljc files.

[expez]

It works as expected in clj and cljs files but when in a cljc file I expected both repls to change.

It seems this only acts on the current-connection in cljc files.

[Malabarba]

Yes, we have no special support for cljc files, so everything still acts on the current connection.
We cannot make it so that every request is dispatched to both connections (it's not infeasible, just undesirable), so this would have to be implemented on a per-command basis.

That's said, it's not clear to me that we should implement this, just because I'm not aware of what people workflows are with cljc files. What would be the least surprise here?

[expez]

What would be the least surprise here?

I expected both repls to change.

I suppose that was somewhat colored by my not being able to identify what the current-connection was. I still don't know how to change the current-connection, though.

I'm not aware of what people workflows are with cljc files

When I'm working on a cljc file I'm working on a single feature, but I'm either working on the clj part of that feature or the cljs part and I'm jumping between these two contexts. What I'm not doing, which the current implementation makes easy, is working on two unrelated features. So rather than look upon this as destroying the context of the other repl I think it's more helpful to think of it as bringing them in sync.

In fact, this is what I'd like for almost all functions. E.g. C-c C-k should bring both repls up to date with the content of the current file so I can quickly verify that the cljs and clj features work the same.

[bbatsov]

Yeah, that's a pretty interesting predicament - in the case of ambiguity we should either prompt users to decide what connection to use for the evaluation or should just eval in both connections always. The second option seems a more reasonable default. Alternatively you can have a command toggling between "use clj", "use cljs" and "use both".

[Malabarba]

I think this improvement will require more infrastructure for determining the context (similar to what Lars has done in clj-refactor) and then some clever design in terms of dispatching and handling return values.

While I agree this is all worth doing, in my opinion it involves a little too much change to be doing so close to a (possible) release.

[bbatsov]

What's the relevant code in clj-refactor? Perhaps we can reuse it here.

[expez]

What's the relevant code in clj-refactor?

It's here. All it does is find the language context by checking where in the reader conditional point is.

[bbatsov]

Hmm, looks like something that could easily be in clojure-mode.

[bbatsov]

I think this improvement will require more infrastructure for determining the context (similar to what Lars has done in clj-refactor) and then some clever design in terms of dispatching and handling return values.

While I agree this is all worth doing, in my opinion it involves a little too much change to be doing so close to a (possible) release.

Maybe you're right. I'll definitely not have that much time to work on CIDER before the end of the month, so if someone wants to see this land in 0.10 they should work on it themselves.

[expez]

I think this discussion belongs in the issue about jumping to vars. This issue doesn't require any logic like that to be solved (act on all siblings in the project so they are in sync)

[bbatsov]

Yeah, for this particular operation the multiple requests will not be an issue, as there's no feedback that can be interleaved.