cursive

Issues at: https://git.io/cursive-issues
kenny 2021-04-26T00:04:10.254600Z

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'".

cfleming 2021-04-27T08:30:25.267200Z

Thanks for the issue, I’ll take a look.

kenny 2021-04-26T00:08:52.254900Z

Working example from 1.10.1-eap3-2020.3.

kenny 2021-04-26T00:10:24.255300Z

Updating to Cursive 1.10.2-2020.3, breaks the spell check.

kenny 2021-04-26T00:14:41.255500Z

fyi, https://github.com/cursive-ide/cursive/issues/2538

2021-04-26T22:03:20.260200Z

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?

cfleming 2021-04-27T08:31:47.267400Z

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.

kennytilton 2021-04-30T03:39:35.285900Z

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

cfleming 2021-04-30T07:42:03.286200Z

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).

2021-04-30T14:59:42.287200Z

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.

2021-04-30T21:36:21.290Z

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

alexmiller 2021-04-26T23:06:43.261400Z

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

alexmiller 2021-04-26T23:07:16.262Z

generally I only use the debugger when I'm interacting closely with an inscrutable Java API so I can walk across the interface

alexmiller 2021-04-26T23:07:32.262400Z

usually for Clojure code it's easier to just interactively evaluate code from the source