In cursive, what is it that tries to figure out the line number being executed during single stepping. Is this IntelliJ or is it the cursive plugin? I ask because it seems to do a pretty bad job. My code single-steps, but the line displayed in the editor is completely wrong.
> my suspicion is that cursive is assuming the package name is the same as the file name. This is possible, or some similar type of bug. I’ll try to take a look at this.
If it is the responsibility of cursive, then it is probably possible to fix. if it is intelliJ that just makes me cry.
😥
Those numbers are written into the bytecode, and they’re basically always correct. However, they’re correct for the moment at which you compile a particular piece of code, which in the case of Clojure means when you sent it to the REPL. So in particular, if you’re editing functions and then sending them to the REPL, odds are that the lines compiled into the functions appearing after the ones you sent are now incorrect. The safest thing to do is to send the entire namespace before debugging.
Hi Collin is it cursive who is responsible for writing these into the byte code, or is that some magic of the jvm or intelliJ?
I believe my byte-code line numbers must be wrong from the outset, because I don't think I'm doing any redefinitions in the repl.
my suspicion is that cursive is assuming the package name is the same as the file name.
however, it might be that java/maven/intelliJ is making this assumption.
Clojure is the one writing that into the bytecode
is there the equivalent of reverse i-search in the Cursive REPL? using nREPL
as the type, Run with Leinengen, if that matters
@alexmiller Any idea if there are bugs around this? This project has an unusual layout, e.g. https://gitlab.lrde.epita.fr/jnewton/clojure-rte/-/blob/180118911e37024c9216bd05b9fee93a327095bf/src/clojure_rte/api.clj, where in-ns is used to define things in the core ns from other files.
Tools->REPL->Search REPL History
Thanks