In Cursive 1.10.2-2021.1, it seems IntelliJ's intelligent spell checker no longer works. Screenshot 1 is Cursive 1.10.2-2021.1. "togehter" used to be underlined in green with the inspection saying "Type: In word 'togehter'".
Thanks for the issue, I’ll take a look.
Working example from 1.10.1-eap3-2020.3.
Updating to Cursive 1.10.2-2020.3, breaks the spell check.
Is it just me, or is debugging extremely difficult? Line based breakpoints are close to useless (even if you set -Dclojure.compiler.disable-locals-clearing=true
). Because of the way the Clojure compiler works, I suppose, the context in which you hit each line varies drastically. Sometimes, symbols are in scope at that particular “hit” and other times, not. So that makes it difficult to even set conditions on your breakpoints (because very often the symbol you want to write some condition on isn’t available, yielding an error).
I don’t think this is necessary a Cursive issue, but since I’m using IntelliJ/Cursive with OpenJDK debugger (as I suspect many are), it seems like the closest channel. Anyone have similar experience? How are you managing it?
It’s occasionally a little flakey, but it’s not usually that problematic. I’d be interested in seeing a screenshot of the debugger in a case where you’re not seeing locals you think you should be.
It is "just you", in the sense that you choose to do interactive debugging. Just pour in the print statements, sit back and see the bug appear: https://tilton.medium.com/the-mind-is-a-terrible-thing-cc2ca0293095
I’d respectfully disagree with that, I do use print debugging sometimes, but I also spend significant time in the debugger too - both are useful. The debugger is also significantly more useful in languages like Java, it’s unusually finicky in Clojure (for various reasons, including the relative immaturity of Cursive).
yeah, an interactive debugger can be indispensable in certain cases. other times, adding some print statements helps fix the issue. and of course, we have the REPL which is extremely powerful.
a technique I just “rediscovered” (since I figured it out like a year ago, then forgot) is to call (def crazy-value …)
from the debugger evaluator window, which will put that thing into your local namespace to play around with at your leisure.
sadly, what I’m finding lately is that attaching the debugger and setting a few line breakpoints (even unconditional) slows down the program execution by 100x or 1000x, and if that happens, it’s unusable
in general, you'll get a "step" for each expression - sometimes it helps to keep that in mind if you're walking through (or even to break up the code into more lines temporarily to make it clearer
generally I only use the debugger when I'm interacting closely with an inscrutable Java API so I can walk across the interface
usually for Clojure code it's easier to just interactively evaluate code from the source