Fork me on GitHub

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?


Whoops, just realised there’s an #emacs channel too.


@orestis disclaimer: I’m a spacemacs user too, and mostly quite happy with it. that said, if you look for an alternative, check out, which also has prelude-evil


without having it tried myself, I would guess it works very nicely with cider 😉


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.


I do hope that we’ll support Emacs 25 for an extended period of time.


I was wondering what could prevent somebody from updating


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.


I hope this makes sense. 🙂


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’ll have a look in the coming days, thanks for your time 🙂


You’re welcome!


I have a project that starts it’s own nrepl server (as in I’m still able to do this in cider 18, but I’m unable make the switch from -> 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: #’ found for class: nrepl.transport.FnTransport :via [{:type java.lang.IllegalArgumentException :message No implementation of method: :send of protocol: #’ 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 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


(before I spend too much time debugging)


@norman Use nrepl/nrepl 0.4.5 instead of tools.nrepl and I think all will be good for you.


Thanks - let me try that


Nope. Going from 0.4.4 to 0.4.5 didn’t fix it.


> [org.clojure/tools.nrepl “0.2.12”]


I was referring to this.


I hope this makes sense.


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 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


Ops, I completely misread your example.


No - I meant I’m starting my embedded server like that, to work around the NPE


cause No implementation of method: :send of protocol: #' found for class: nrepl.transport.FnTransport
[{:type java.lang.IllegalArgumentException
  :message No implementation of method: :send of protocol: #' 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 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.


Notice the different namespace prefixes.


Yes - I’ve updated all my namespaces to use nrepl.server and not


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.


I guess you can check what does find-ns returns for you.


(sorry about the incoherent responses - I’m juggling a few things at the same time)


No problem - it does give me some places to look and confirms that there aren’t any other known problems that should make it fail


Followup - if I don’t apply the 447 hack, I don’t get any errors. That’s interesting.