Fork me on GitHub
#cider
<
2016-02-26
>
bozhidar06:02:28

I'm guessing it makes sense to just bake this into CIDER - the ability to save the history more frequently

bozhidar06:02:41

the current situation is simply legacy from SLIME

bozhidar06:02:33

we can also add fancy stuff like project-specific history, which would be pretty cool IMO

nkraft17:02:37

Anyone here using Emacs Cider on OS X? It used to work great but today cider-jack-in gives: "cider-project-type: Symbol's function definition is void: closure-project-dir". Any ideas for fixes?

bozhidar17:02:21

closure-project-dir?

bozhidar17:02:28

or clojure-project-dir

bozhidar17:02:40

it might be that you’re using an old version of clojure-mode

bozhidar17:02:49

as this function is actually defined in it

nkraft17:02:34

My closure-mode is 20160213.1437, so that's pretty up to date.

nkraft17:02:24

Sorry, that should be closure-mode.

nkraft17:02:37

(^(& spell correction.

nkraft17:02:47

Clojure not closure mode.

echristopherson17:02:32

bozhidar: looks like it's in cider.el?

nkraft17:02:33

That's odd. Looks like autocorrect has been the problem here. That error I posted should read "definition is void: clojure-project-dir"

bozhidar17:02:03

that’s a function invocation

bozhidar17:02:15

the definition itself is in clojure-mode

echristopherson17:02:17

oh, you mean clojure-project-dir function

nkraft17:02:31

I saw that, just not sure why it stopped working. Hoping someone had a quick fix.

echristopherson17:02:48

sorry, I was thinking of cider-project-type

bozhidar17:02:10

reinstall clojure-mode

bozhidar17:02:19

can’t think of any other quick fix

nkraft17:02:23

Thanks. I tried that, but no change. This is one of those reasons I have a love-hate relationship with Emacs. Oh, well. I'll use another clojure editor until I figure this out.

echristopherson18:02:20

Yeah, I don't like dealing with versions of lein, nrepl, and cider

echristopherson18:02:53

I'd like a way actually that I could explicitly version my emacs packages and check the versions into source control

nkraft18:02:37

That sounds like a useful tool to have. It might make Emacs upgrades a lot easier.

malabarba18:02:25

You're free to version control your .emacs.d directory, or even just .emacs.d/elpa, which is where the packages go.

malabarba18:02:16

As for the problem. This sort of thing shouldn't happen on a regular basis. Of course, package developers might make mistakes and ship broken packages, but that's fairly rare. There's nothing intrinsic to Emacs' package manager that would lead to function-not-defined errors. If this sort of thing happens regularly to you, I'd encourage cleaning out your config and your personal lisp directories. Something is broken in there.

nkraft18:02:49

My love-hate relationship with emacs goes back more than 20 years. My config and lisp files are really quite small these days. And it's not just packages that can be an issue, as these packages interact with applications outside of emacs, like lein and nrepl, and are often sensitive to version changes in those external utilities.

echristopherson19:02:52

@malabarba: I do VC my .emacs.d. But right now I don't know of a sensible way to actually manage .emacs.d/elpa so I can roll packages back. I'm open to ideas though.

echristopherson19:02:58

I guess I should learn how that tree's actually laid out even

malabarba20:02:00

You can make a commit for each package (containing the deleted and the added directory) whenever you upgrade your packages. That's a bit of manual work, but I wouldn't be surprised if someone has written a way to automate it. simple_smile

malabarba20:02:25

You can also just make a single commit every time you upgrade everything. Then you at least have easy snapshots you can fall back on

echristopherson21:02:05

I tried using a submodule for each of my vim plugins. I really tried. But some plugin or other always broke before long.

echristopherson21:02:40

I think what happens is that people force-push stuff over their public repos, and my plugins have refs to commits that no longer exist. :shrug:

nkraft21:02:19

I go through similar things sometimes. Someone will push their latest to the public repos, with a dependency on a version of a package that isn't in Melpa or the other repos yet. At that point, I just have to wait until everyone catches up. Sometime they don't and I have to Github it and install manually. It's a lot of work to keep Cider up and running sometimes.