Fork me on GitHub

@bhauman Haven’t had time to look at this. Hopefully next week will be less busy.


@bbrinck I not quite sure what you want to configure and how you want to do it. Generally you can configure certain things on a per-project basis using .dir-locals.el, and potentially you can have an on-connect hook that loads some file after you’ve connected.


An on-connect hooks sounds promising. I’ll look into that. Thanks!


If i'm starting a Figwheel Main project from CIDER, and Figwheel Main fails to start due to a syntax error, CIDER is unable to start CLJS REPL and does try not recover afterwards.


Now nREPL is running, but I don't see a way to deal with it beyond killing and starting anew.


@bhauman ^ maybe it's something figwheel-main should handle?


@U07HVGQJ3 yes figwheel.main is vulnerable to your initial build failing


it does seem that it should not launch the REPL or server if it fails


but no you can recover if you fix the code and reload the page


at least I think thats how it works on the command line


it should work that way with nREPL as well


There should maybe be a cider command that sends the figwheel-main (or others) forms over the same connection - maybe there is already but haven't investigated the new API in depth enough

Karol Wójcik18:08:57

How to force the repl to show user.ns=>? The context: The figwheel-main prints the info about compilation to the repl. After the message repl does not return to user.ns=> while it should. Is there a way to somehow send a request to repl which triggers the cider user.ns=>?


Getting this error suddenly on a project I've been working on for weeks while trying to jack in:

[nREPL] Starting server via /usr/local/bin/clojure -Sdeps '{:deps {org.clojure/tools.nrepl {:mvn/version "0.2.13"} com.billpiel/sayid {:mvn/version "0.0.16"} refactor-nrepl {:mvn/version "2.4.0-SNAPSHOT"} cider/cider-nrepl {:mvn/version "0.18.0-SNAPSHOT"}}}' -e '(require (quote cider-nrepl.main)) (cider-nrepl.main/init ["com.billpiel.sayid.nrepl-middleware/wrap-sayid", "refactor-nrepl.middleware/wrap-refactor", "cider.nrepl/cider-middleware"])'...
error in process sentinel: nrepl-server-sentinel: Could not start nREPL server: Exception in thread "main" Could not locate nrepl/server__init.class or nrepl/server.clj on classpath., compiling:(cider_nrepl/main.clj:5:1)


cider switched to nrepl 4.0 from tools.nrepl 2.x.


that said, you're going to run into issues with sayid and refactor-nrepl. I think there is a new release of refactor-nrepl and I think there is an unaccepted PR to fix sayid


if you don't feel like mucking about with that i think you can go back to cider 0.17.0 or you can play the update game and see what happens


@dpsutton how do I go back to 0.17.0 and stay there?


This is probably the third time that I've sat down to work only to find my Clojure environment completely broken


I just want something stable, don't care about latest nrepl stuff


Putting `(setq sayid-inject-dependencies-at-jack-in nil) in your dotspacemacs/user-config is all that is required now as far as I can tell (under spacemacs develop branch).


omit the `


@pauld thanks, what does that do exactly? I'm eager to find a way to "freeze" spacemacs to stop it constantly changing out from under me.


Every google turns up mountains of Github issues of people requesting the same, but to no avail


Someone else gave me that tip, but I think it just prevents the broken say-id package from pulling in it's obsolete dependencies.


That's the workaround until sayid is fixed


refactor-nrepl was fixed


As far as spacemacs breaking, I don't have a good solution. It seem more of an issue with using MELPA. You can switch to MELPA stable - that may help.


That would pin cider to an older version, etc.


@pauld ah I see, thanks. Yeah I've read lots of discussion around MELPA on Github, but it doesn't seem to be moving anywhere. I've tried every "workaround" for using MELPA stable I can find and none of them seem to work anymore.


yeah there's also a way of using melpa stable for particular packages if I recall correctly


or was it the other way around? specifying which packages using non-stable...


Everything I've read is pinning packages to MELPA stable


But none of them seem to work unfortunately


It seems like MELPA itself might be fundamentally flawed


So far it's been sayid that has broken things for me twice, but I've learned 2 trick on how to disable it now


Hm...why is sayid able to break an editor that was working yesterday is my question


I think maybe spacemacs is too bleeding edge for my taste haha


I think it's just that spacemacs clojure layer uses sayid. Sayid would have broken regular emacs users too if they were using it - I think.


Just like refactor-nrepl broke too.


It's more a problem of cider and some of the plug-ins or related packages in the ecosystem.


Bummer...this might be the straw that breaks the camel's back for me as far as using spacemacs goes. Think I'll switch to something with a proper package manager.


I don't think this is a spacemacs specific issue technically.


But I feel your pain


Sure, maybe the "emacs ecosystem" is more accurate. I really need to be confident that I can start the REPL and work day-to-day...need my editor to be rock solid.


My very idealistic view on this is that emacs is notoriously THE hacking editor, so I would say that you kind of need to be prepared for some breakage and, if time allows it, try to help with the fix/fix it yourself. I have choosen emacs because I like to hack on it emacs


I enjoy not to be productive for some time and help other fella in the meantime 😄


It does indeed feel like emacs is constantly being "hacked" 😛


I can empathize with that though. I like sharpening my tools as well, but sometimes I really want to sit down and try an idea, only to find that emacs won't boot


yeah well, that happens to me as well, but the fix is usually a small tweak


(or maybe now I now how to take cider and nrepl 😄 )


Another way to see it is that I so hate to get stuck that I have always preferred to dig into the problem...


Well, for what is worth - the big changes are more or less behind us, so we should be looking at a period of much improved stability down the road. But I have to say again that I find it amusing that people tracking CIDER’s development branch expect it to be super stable - it’s called “development branch” for a reason. 😉


0.18 experienced an unusual amount of massive changes, but this should certainly make things much more stable down the road.


Obviously we don’t plan to do another nREPL migration or another connection management rewrite ever again. 🙂


If it were possible to not track CIDER's development branch, I'd definitely be doing so. I haven't found a way as of yet.


And, of course, if Spacemacs stuck just to bundling CIDER without any extensions almost no one would have experienced any nREPL-related breakages. CIDER’s ecosystem is outside the control of any single person, so coordinated updates between many packages can be painful.


@cjsauer Stop using Spacemacs, install it from MELPA Stable, end of story. It’s as simple as that. 🙂 (and it’s documented in the manual).


Anyways, at this point it’s pointless to go back to 0.17. There are no more changes planned for 0.18. I think it’s in a decent shape and it will be promoted to the new stable in the next couple of days most likely.


I’ll give it a go. Wish I would’ve known what a crutch Spacemacs would be...reimplementing the layers I’ve come to know seems a bit daunting.


There should be a big yellow warning on the homepage: “can not use stable packages of anything”, lest more Clojure users amuse you in the future.