Any thoughts on why I get No cljs REPL in current session after starting a with C-c C-x j m (`cider-jack-in-clj&cljs`)? (using custom form) - I have two nREPL-buffers (same port number), one with a clj-repl, the other with cljs.

Can I instruct CIDER/sesman to mark the current repl-buffer as a cljs-buffer somehow?

Buffers become cljs buffers automatically when piggieback starts up. Even if you mark a buffer manually as a cljs buffer if piggieback’s not running normally this wouldn’t help much.

When exactly do you get the error?

I get the error when doing C-c C-z from a cljs-buffer.

Maybe it is not part of the current sesman-session somehow?

the infobar says cider[not connected] in the cljs-buffer (clj-buffers are connected)

sesman-info gives work/trip-trap:localhost:62550 [*cider-repl %s(clj)*<2>, *cider-repl %s(clj)*] linked-to proj(~/work/trip-trap/)

which looks to me like both repl-buffers are linked

it is <2> that is a cljs-buffer

Seems to me that the ClojureScript upgrade did go well for you and that’s causing the problem. You should take a look an the nREPL message exchange on startup and see what’s happening with respect to track-state.

will do. How do I look at the nREPL message exchange?

@bozhidar I have now enabled the nREPL-logging, and connected again (fresh emacs). This time, C-c C-z from my clj-buffers go into the cljs-repl. I also found this:

(<--
  id                 "10"
  session            "523c9f17-8533-4cfa-8445-f338ae9b6424"
  time-stamp         "2018-08-22 10:17:50.454340000"
  changed-namespaces (dict ...)
  repl-type          "clj"
  status             ("state")
)

of note, I also get the server-side log messages interspersed with cljs-log messages in the cljs-repl-buffer

the custom code to connect to figwheel is basically fw/start-figwheel! followed by fw/cljs-repl

Well, it really seems the repl type detection is broken for you for some reason. Are you using the latest piggieback, figwheel, etc?

The check in the middleware is pretty trivial - it just checks for some vars being present.

If the REPL is truly a cljs repl you can force the type with M-x cider-set-repl-type, but if it’s not that’s going to revert on each eval.

[com.cemerick/piggieback "0.2.2"] and [figwheel-sidecar "0.5.16"] seems to be the latest?

yeah, it reverted after the eval

Oh, problem solved then. 🙂

It’s now cider/piggieback and it’s something like 0.3.8 🙂

aha!

doh, sorry for taking so much of your time on something like that

No problem.

thanks for on point and quick help 🙂

Any time!

Btw, I was in Oslo until yesterday. Should have thought of checking up on you for a beer and an Emacs/Clojure chat. 🙂

ooh, yeah! Next time 🙂

Definitely!

@bozhidar is the new nrepl-cmdline writing a .nrepl-file somewhere?

was trying to connect automagically with cider and/or cursive

no it looks like it does not

Hi. Not sure if this has to do with Cider: Is there any way to make projectile-find-file or something similar include all dependencies from the current lein project?

@richiardiandrea No, it’s not. That was on my todo, but I ran out of time.

The only reason I didn’t add it was that I wasn’t sure where exactly to write it. I was thinking of the current directory with an option to supply the path to it.

PRs welcome! 😉

@andre.peric Include them how? Projectile’s meant to search only within a project’s directory, so likely the answer to your question is no.

@bozhidar by listing them, basically. Yeah, I was looking for something similar to Intellij, which can list dependencies files as well

After upgrading to the latest Cider snapshot (today’s), I’m getting this when I try to cider-jack-in:

Same error if I pick clojure-cli from the list

(cider-jack-in-command "lein") returns "lein" for me. what does it say for you?

do the same with cider-jack-in-resolve-command, cider-jack-in-global-optionsand cider-jack-in-params to see which one is problematic. or you could set toggle-debug-on-error and see which one is complaining

I would guess the resolve command one

(cider-jack-in-command "lein") gives the same error

interesting

that's quite strange. that function is just pattern matching

can you navigate to that function and see what's up with it? debugging won't help much but just see what it looks like and maybe re-eval it?

https://github.com/clojure-emacs/cider/blob/master/cider.el#L321-L329 <-- looks like it expects a symbol, not a string?

ah maybe i'm out of date 🙂

ok. pulled changes 🙂

do you have dir locals for your project?

I’m not sure what that is

because errors with 'lein as a symbol show up as > user-error: Unsupported project type ‘lein’ and errors with "lein" as a string show up as > user-error: Unsupported project type ‘"lein"’

have you restarted emacs since upgrading?

yes

do you know how to evaluate random snippets of emacs lisp?

yes

ok. there are so many different levels of emacs comfort

didn't mean to sound condescinding

can you eval cider-project-type from a buffer in your project

No, that’s fine, my level of knowledge is pretty low, but I know how to eval

sure

perfect

Hmm, maybe I don’t understand how to do that. I know how to eval emacs lisp in emacs lisp buffers and with M-: but I don’t know how to eval an Emacs lisp expr in the context of a Clojure buffer.

exactly as you just said. with M-:. We just need it to be rooted in a buffer in the filesystem which that will do

it's gonna go searching the directory for build files to identify what type of project you're in so we need it to run from a good starting point.

OK. When I do that I get an error: Debugger entered--Lisp error: (void-variable cider-project-type)

well that's interesting. CIDER doesn't appear to be loaded

I see cider[not connected] in the modeline, if that means anything

can you execute `(cider-version) and tell me what you see?

CIDER 0.18.0snapshot (package: 20180822.1325)

and (cider-project-type) throws that error above about void variable?

@enn Are you sure you’re on the latest build? I had made a small mistake that would explain your problem, but I addressed it only a few minutes later and I’d be pretty surprised if MELPA managed to build the package exactly then.

@bozhidar that version is the same listed as the latest at https://melpa.org/#/cider. I’m not sure how to check beyond that.

Hmm, maybe they really built then. Can you check if the locally installed package looks like the code before or after this commit https://github.com/clojure-emacs/cider/commit/cc458a4b2c1ab3ebd4ff6e955021eb3b12c4be34

checking…

@bozhidar the package looks like the code after that commit

What’s the full backtrace for your error? I simply can’t imagine where is the "lein" string coming from.

Hmm, I can’t find a backtrace. *Backtrace* is empty and the minibuffer just has the one line (even with debug-on-error set to true)

Yeah, my bad. There should be a backtrace, of course.

Seems for some reason the project type for you is detected a string, although this shouldn’t be the case.

Ideally you should debug cider--update-jack-in-cmd with Edebug to see what’s exactly is amiss for you.

I’ve tested things locally and everything seems to be fine.