Detect the repl type in cider-sync-request:info based on the current buffer

[ak-coram]

cider-sync-request:info is using cider-nrepl-send-sync-request without a connection argument, which leads to (cider-current-repl 'any) being used to determine the current connection. This means that when M-. (cider-find-var) is used in a cljs buffer it still sometimes tries to (unsuccessfully) find vars via the clj session of the project. I've added an explicit connection argument to the cider-nrepl-send-sync-request call in cider-sync-request:info using (cider-current-repl) (which determines the repl type based on the current buffer). This resolved the issue for me.

---

Before submitting the PR make sure the following things have been done (and denote this
by checking the relevant checkboxes):

• The commits are consistent with our contribution guidelines
• You've added tests (if possible) to cover your change(s)
• All tests are passing (make test)
• All code passes the linter (make lint) which is based on elisp-lint and includes
  • byte-compilation, checkdoc, check-declare, packaging metadata, indentation, and trailing whitespace checks.
• You've updated the changelog (if adding/changing user-visible functionality)
• You've updated the user manual (if adding/changing user-visible functionality)

Thanks!

If you're just starting out to hack on CIDER you might find this section of its
manual extremely useful.

[ak-coram]

I've noticed that cider-sync-request:eldoc has the same problem because nil is passed as the connection. I can add another commit for that as well if you'd like.

[ak-coram]

Probably the same also goes for cider-sync-request:complete and possibly several other functions, but I'm not really sure about the ones related to namespaces (and the ones for specs).

[bbatsov]

I recall we discussed something like this with @kommen recently, but I'm fuzzy on the details and whether we actually decided on anything. I agree that picking some random connection is not the best way to go, and what you suggest seems reasonable.

I've noticed that cider-sync-request:eldoc has the same problem because nil is passed as the connection. I can add another commit for that as well if you'd like.

Yeah, that's weird. In such cases nREPL will create some transient session for the duration of the request.

[kommen]

This is the PR where we discussed this: #2467

I think we we came to the solution we have right now because of this comment:

Looking at the other code in the file I think of two things:
what happens if you only have a cljs connection? Seems to me the formatting should still work, as it's not really clj or cljs specific

#2467 (comment)

[ak-coram]

Instead of having to figure this out for each request type, maybe having cider-current-repl prefer repls of type (cider-repl-type-for-buffer) when called with 'any would be the easiest solution. It could still pick the most recent one available, but if there are any with the current buffer's repl type then pick the most recent one of those. I'll gladly update this PR if you prefer this solution.

[bbatsov]

That seems somewhat reasonable. Keep in mind that relatively few ops have ClojureScript specific versions, so we should probably focus only on those. I'd aim to replicate whatever dispatch logic we're using for eval, as the most fundamental op.

Also keep in mind that the terms clojure and clojurescript connection are a misnomer - all connections are actually the same, the "clojurescript" connections simply use an nREPL session where Piggieback is present. If you pass the right nREPL session to an operation it would work regardless of the connection used. The ClojureScript connection simply has as its session this piggieback nREPL session. Hopefully that's not super confusing. See also https://nrepl.org/nrepl/design/middleware.html#_sessions

[bbatsov]

To summarize again - we need some more specific routing only for ops that have ClojureScript versions. Currently I think those are only "eval" (which should have it done right by now), "complete" and "info".

[bbatsov]

Also - rebase on top of master to fix the build error.

[ak-coram]

I've rebased on top of master and added another commit for the
"complete" and "eldoc" ops (as eldoc isn't working for me reliably
without this change either).

[kommen]

Thank you @ak-coram!