Fork me on GitHub
Krishan V05:08:08

Hey everyone, what is the keybinding for evaluating current form that my cursor is on? Alt Shift P evaluates the top level form but I cannot find the binding for current form


You can move your cursor to the end of the form, after the paren, like so (+1 2)| and invoke Send form before caret to REPL . There isn't a Send current form under caret to REPL, I'm guessing, since it'll be literals or symbols 95% of the time that'll be the current "form".


Or you could just select the form you want to evaluate and call either Send form before caret to REPL or Send Top form to REPL.

Krishan V08:08:18

Thanks @UMPJRJU9E. I'll go with using Ctlr + W to semantically choose the form I want to evaluate and use Send Top form to REPL . Gets the job done :thumbsup:


There is expand selection and shrink selection, if you haven’t already used it, which works quite nicely with s-expressions and will allow you to easily select the desired form.


Can anyone provide me with more insight as to why this happens: ? I am not the original requestor, but my team all received the same sort of error from Cursive when we upgraded a library version (In our case it was time.clj -> time.clj -> time.clj. Again, turning off Load out-of-date file dependencies transitively seems to have fixed the error, but I don't understand why, or what is causing that error in the first place. It seems to be incorrect, as the code compiles and runs fine, and Emacs/CIDER doesn't have any issues.


This tends to be something funky with cljc. Do you know where the time.clj file comes from?


I don't, unfortunately. This occurred in pure clj code, rather than cljc. The issue arose when we upgraded the version of manifold we were using from the one that caesium bundles to 0.1.9-alpha5 (via an exclusion on caesium in deps.edn and an addition of the new version)


If you use Navigate-&gt;File…, set the filename to time.clj and set the scope to “All Places”, what does it find?


It's finding a whole load of time.clj instances in libs, as well as the one in my actual project. It is finding 2 different versions of it in manifold (the lib we upgraded), both in the m2 cache, one for version 0.1.8 and one for 0.1.9-alpha5. Is it potentially getting confused between the two versions?


Going to try removing the old version


Hmm, even though I'm excluding the instance of manifold 0.1.8 it still gets pulled 😞


Where’s it coming in from? You should be able to see that in either your deps or lein toolwindow


So clj -Stree and the lein toolwindow both say it's within byte-streams, which in turn is within caesium, but that's what's excluded:

clj -Stree
com.github.arohner/manifold 0.1.9-alpha5-top
caesium/caesium 0.13.0
  . com.github.jnr/jnr-ffi 2.1.12
    . com.github.jnr/jffi 1.2.23
    . com.github.jnr/jffi$native 1.2.23
    . org.ow2.asm/asm 7.1
    . org.ow2.asm/asm-commons 7.1
    . org.ow2.asm/asm-analysis 7.1
    . org.ow2.asm/asm-tree 7.1
    . org.ow2.asm/asm-util 7.1
    . com.github.jnr/jnr-a64asm 1.0.0
    . com.github.jnr/jnr-x86asm 1.0.2
  X commons-codec/commons-codec 1.14 :use-top
  . byte-streams/byte-streams 0.2.4
    . primitive-math/primitive-math 0.1.6
    . clj-tuple/clj-tuple 0.2.2
    X manifold/manifold 0.1.8 :excluded
  . org.clojure/math.combinatorics 0.1.6
  X medley/medley 1.2.0 :use-top
  X com.taoensso/timbre 4.10.0 :use-top


Actually, you could try this: go to Help | Diagnostic Tools | Debug Log Settings…. In the box that opens, enter #cursive.namespace. Then repro the problem and check your log (Help | Show Log in Finder/Explorer) for a “Dependency cycle” log that should have more information about the actual files involved.


But for some reason if I delete the directory for 0.1.8 from ~/.m2/repository it still pulls it in again the next time I run lein repl


Aah cool, will do


But wait - are you using lein or deps? Or are you using lein with dependencies from deps.edn?


lein with dependencies from deps.edn at the moment


I’d be interested to see that log entry as well.


If you do clj -Spath, does that appear on the classpath?


The 0.1.8 version? Nope


Just reproing 🙂


That’s interesting. I wonder if that’s a bug in Cursive because it’s not expecting to receive excluded deps back in the tree.


To be honest, neither was I 😉


Hehe. Does it show up in lein classpath?


Or lein deps-tree?


... huh. It doesn't. At all. caesium is there, but no version of manifold, 0.1.8 or 0.1.9-alpha5, is mentioned (for lein classpath)


Is your project imported into Cursive using lein or deps?


Ooh, that's interesting


lein deps :tree output:

 [byte-streams "0.2.4"]
   [manifold "0.1.8"]
 [caesium "0.13.0" :exclusions [[manifold]]]


So because manifold is a sub-import of byte-streams, it's not correctly outputting/handling the exclusion? Or is that just a display thing


clj -Stree seemed to be interpreting it correctly


Ok, so I think that’s the problem. I’d have to go back and check the code, but from memory Cursive uses that to work out which libs to sync. Or at least the API under the hood that produces that tree. So with a bit of luck I might be able to shunt the blame onto the lein plugin 🙂


Although it’s entirely possible that it’s a bug in Cursive and that’s just a visual thing.


Well lein deps outside of Cursive also pulls in 0.1.8, so I would guess it's not just a display oddity?


Probably not, no.


That’s very weird.


Any luck with the log?


Just getting one with minimal cruft. I had a load of IntelliJ namespaces at trace level in there before


2021-08-13 11:35:22,676 [  90382]  DEBUG -             #cursive.namespace - Dependency cycle /Users/meyersd/.m2/repository/com/github/arohner/manifold/0.1.9-alpha5/manifold-0.1.9-alpha5.jar!/manifold/time.clj -> /Users/meyersd/.m2/repository/manifold/manifold/0.1.8/manifold-0.1.8.jar!/manifold/time.clj -> /Users/meyersd/.m2/repository/com/github/arohner/manifold/0.1.9-alpha5/manifold-0.1.9-alpha5.jar!/manifold/time.clj


I could send the whole thing through if you think it'd be useful


No, that’s the interesting bit, thanks.


So it’s definitely getting confused between those versions for some reason


Ok, I need to go to bed - it looks to me to be a problem in the lein-deps plugin, but I can’t rule out a Cursive bug there. Could you create a small repro repo that I could look at (I’m assuming the real one is a work thing?) and then I can debug the API coming back from lein to be sure.


Cool, no worries, will do. Add to the existing issue I linked?


Or is this potentially a different thing?


Good question. Perhaps create a new one, and if it looks like the same problem I’ll link them. I’ve never seen this in clj-only files, it’s usually someone doing something funky with cljc like requiring macros from the same file or something like that.