Fork me on GitHub
#cursive
<
2017-10-31
>
kennytilton15:10:58

Hunh. I have two CLJC projects. In the old one after I start a REPL in IntelliJ I can evaluate (+ 2 2) in the input area and see 4 in the output. With what seems to be an identical run configuration, (after duly switching the to the NS of the same source file) (nrepl with leiningen) I get “unable to resolve symbol +”

kennytilton15:10:18

That rings a bell from when I last worked on CLJ in anger, but I thought it arose from forgetting to switch the REPL to a clojure namespace. I do see a confirming message that the correct NS is operative:

`(in-ns 'tiltontec.cell.base)
=> #namespace[tiltontec.cell.base]
`

alexmiller15:10:06

when you switch via in-ns, that doesn’t actually refer-clojure (something ns does for you)

alexmiller15:10:28

you can correct at this point by doing (clojure.core/refer-clojure)

kennytilton15:10:33

Ah, OK, that sounds familiar.

alexmiller15:10:18

I think the question is what “duly switching” means :)

alexmiller15:10:22

if you’re working at the repl, you can instead (require 'tiltontec.cell.base) (in-ns 'tiltontec.cell.base)

kennytilton15:10:27

Thx! Come to think of it, when I did this before (a year ago) I was using Emacs and I think Cider takes care of that. Now I am curious how I got the other project working just now! (Meanwhile, refer-clojure worked great.) Hmmm, I guess I could also send the (ns…) form in the source to the REPL.

alexmiller15:10:11

in cursive, I often use the “Load file in REPL” Cursive key binding to re-load the file I have open in the editor

kennytilton15:10:16

Ha-ha, yes, I should have said “duly executing menu item “Switch REPL NS to current file”. There is no room for ambiguity in help requests!

alexmiller15:10:16

yeah, that just does in-ns, which won’t cause a load

kennytilton15:10:08

Hunh. Should I be getting a stack overflow error in the Cursive plugin when I open a project? (I just let IJ report it.)

bradford15:10:23

Any news on 2017.3 support? ❤️

kennytilton16:10:33

OK, never mind, the two project files show copious differences, one of which I am sure explains the issue.

kennytilton18:10:54

I just had to disable Cursive to delete a blank line. Anyone else had that? I saw this on two different MacBooks/installations.

cfleming21:10:40

@hiskennyness No, you shouldn’t get SOEs, but you might - just report them and I’ll take a look. CLJC files are prone to them unfortunately.

cfleming21:10:51

@bradford Yes, works fine 🙂

cfleming21:10:18

@hiskennyness No, you shouldn’t have to disable Cursive to do anything - what was the problem deleting the line?

ckarlsen21:10:08

any ETA on the next EAP? Really looking forward to namespace aware navigation 😄

cfleming22:10:35

@ckarlsen Should be in the next couple of days, sorry for the delay - a couple of changes have taken longer than expected.

cfleming22:10:21

This EAP has suffered from the terrible creeping yak shave.

kennytilton22:10:45

@cfleming I wonder if the SOE was just because I was on my old anemic (4g ram) Mac? I do not get it on my new 16g toy. But the little guy was not showing RAM pressure in the Activity Monitor. Sadly the "k" key on my new toy has me headed back to the shop, but such is life.

kennytilton22:10:31

@cfleming OK, on the undeletable line (including simple blank lines) I now have it highly reproducible. I had copied the code snippet below into my source as a reference while hacking away, and commented it out with the #_ block commenter. That is sufficient to make lines undeletable (including defeating deletes when on populated lines in front of any content):

`(#?(:clj dosync :cljs do)
(with-integrity (:change (c-slot c))
    (c-value-assume c new-value nil)))
`

kennytilton22:10:38

Forget the surrounding backquotes above.

kennytilton22:10:19

I mean, those are not in the source, just my faulty markup attempt.