This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-02
Channels
- # 100-days-of-code (1)
- # announcements (2)
- # beginners (122)
- # boot (5)
- # calva (5)
- # cider (54)
- # cljdoc (1)
- # clojure (132)
- # clojure-brasil (1)
- # clojure-italy (4)
- # clojure-nl (6)
- # clojure-uk (105)
- # clojurescript (43)
- # core-async (17)
- # cursive (14)
- # datomic (60)
- # emacs (35)
- # figwheel-main (44)
- # fulcro (70)
- # graphql (1)
- # jobs (19)
- # jobs-discuss (5)
- # leiningen (5)
- # luminus (2)
- # off-topic (40)
- # onyx (2)
- # overtone (5)
- # re-frame (36)
- # reagent (29)
- # ring-swagger (20)
- # rum (13)
- # shadow-cljs (19)
- # testing (5)
- # tools-deps (25)
- # vim (5)
I’m torn. I love the Evil keybindings, I love the “don’t think about it too much” of spacemacs and its somewhat uniform interface, but I hate the fact that I can’t debug any issues that crop up when I’m using it, because too many moving parts and abstractions. What alternatives are there to have a reasonably well-behaved Emacs distribution that doesn’t try to be too clever and also plays well with Evil keybindings?
@orestis disclaimer: I’m a spacemacs user too, and mostly quite happy with it. that said, if you look for an alternative, check out https://github.com/bbatsov/prelude, which also has prelude-evil
a tidbit from the clojurists together q4 results: > One note that came up a few times was that some people had found it hard to update CIDER as they were stuck on older versions of Emacs.
@kommen Yeah, unfortunately I heard about this too late. I didn’t realize that for some people it was problematic to upgrade Emacs, as it’s generally pretty easy.
From what I gathered that’s only a problem for people working in corporate environments when it’s very hard to install “unapproved” software.
being an emacs user for not even 2 years, I didn’t have any experience with this sort of problems
@kommen I never experienced this in 15 years, but I also never worked in a corporate environment. 🙂
@bozhidar do you have time to go a little bit into prelude vs spacemacs from the perspective of someone who doesn’t really how what to choose (other than, vim keybindings are nice)
@orestis Prelude vs Spacemacs is like Arch Linux vs Ubuntu. One is very simple, gives you a nice foundation and you’re supposed to make it your own, the other is very fancy, but modifying it is pretty painful.
Prelude doesn’t use fancy concepts as layers, doesn’t try to bundle every package under the sun, and sticks to the very basics - plain old config split into several files for readability, no heavy handed approach to bundling deps (e.g. Spacemacs bundles clj-refactor, sayid, etc when it comes to Clojure, Prelude bundles just CIDER and assumes you can install the others yourself if you happen to need them).
I even intentionally avoided using package.el in Prelude’s default configuration (even though I like it), as it felt to me that using it in some situations might be might-bending for newcomers to Emacs.
Obviously Spacemacs has a much bigger community and more resources. I haven’t had much time for Prelude lately - I wanted to at least write some manual at some point. Hopefully I’ll get to doing this.
How opinionated is it? I want someone with experience to just make some decisions for me, I shouldn’t have to think about “do I use ivy or helm”. Also, how about evil-mode? I only care about moving around the buffer, I can hit Μ-x manually if needed 🙂
@orestis As opinionated as me I guess. 🙂 OK, probably a bit less. It makes most simple decisions for you (e.g. it uses ivy by default, but also has modules for helm and ido if you prefer them).
The evil config is pretty basic and it wasn’t written by me. I use evil-mode
only as read-only navigation, nothing else. (probably same as you)
I also like doing the various delete/yank motions of vim but I guess these will also be available.
I have a project that starts it’s own nrepl server (as in https://github.com/clojure-emacs/cider-nrepl/issues/447#issuecomment-340223093). I’m still able to do this in cider 18, but I’m unable make the switch from clojure.tools.nrepl.server -> nrepl.server with errors like
2018-10-02 15:10:37,454 ERROR [clojure-agent-send-off-pool-5] {nrepl.misc} - (#error { :cause No implementation of method: :send of protocol: #’clojure.tools.nrepl.transport/Transport found for class: nrepl.transport.FnTransport :via [{:type java.lang.IllegalArgumentException :message No implementation of method: :send of protocol: #’clojure.tools.nrepl.transport/Transport found for class: nrepl.transport.FnTransport :at [clojure.core$cacheprotocol_fn invokeStatic core_deftype.clj 583]}]
In reading back, this seems like it might be because the clojure.tools.nrepl is still on the classpath (because of lein, I assume)
I wanted to check and see if anyone is successfully running an embedded nrepl with the new dependencies
@norman Use nrepl/nrepl 0.4.5
instead of tools.nrepl and I think all will be good for you.
cider-nrepl normally depends on the new nREPL, but will work with the old one in case you used lein repl
/ boot repl
before they updated to nREPL 0.4.
RIght. My description was a little confused. I have an embedded nrepl, but in local dev we still start from lein so tools.nrepl is still getting on the cp
In your case nothing loaded the old namespaces, but you used them in your code, therefore the breakage.
Just being on the classpath is not enough for it to be used - it actually has to be required by something before cider-nrepl
loads (if you want it to use the old nrepl).
Thanks. Our code isn’t requiring clojure.tools.nrepl directly now, but perhaps something somewhere is. That gives me something to look into. If I’m having more problems, I’ll put together a reduced sample project
Now I see you’re actually facing https://github.com/clojure-emacs/cider-nrepl/issues/447
cause No implementation of method: :send of protocol: #'clojure.tools.nrepl.transport/Transport found for class: nrepl.transport.FnTransport
:via
[{:type java.lang.IllegalArgumentException
:message No implementation of method: :send of protocol: #'clojure.tools.nrepl.transport/Transport found for class: nrepl.transport.FnTransport
:at [clojure.core$_cache_protocol_fn invokeStatic core_deftype.clj 583]}]
In reading back, this seems like it might be because the clojure.tools.nrepl is still on the classpath (because of lein, I assume)
When I upgrade to cider 18, all is good. When I upgrade nrepl deps and change the code to use the new nrepl namespace, I get errors. But I am testing within the context of lein 2.8.1 so I still have the old nrepl on the classpath (even though none of my code is using the old ns)
OK, so no completely - I do see that here there’s some mismatch between two version of nREPL.
Yes - I’ve updated all my namespaces to use nrepl.server and not clojure.tools.nrepl.server
So, in this case it seems that the old nREPL somehow gets loaded for you and cider-nrepl binds itself to it, while you’re starting nREPL 0.4 server.