Cursive support

[atroche]

Hey @Engelberg, I completely agree with your rationale, and tried porting some of my code to use better-cond. It became better.

The only problem I had was with Cursive support. It was bad enough to stop me from actually using better-cond. I know there's not much you can do about it, just wanted to add a note of support for what you're doing :)

[Engelberg]

I've actually been using better-cond from Cursive for the past couple of weeks, and have it working well enough that I find it usable.

The key is to put the cursor on the constructs, for example, cond, and click on the lightbulb that pops up. Set the indentation to 0. For defnc, you want to set the indentation to "indent" and set the resolution to resolve as defn. For if-let and when-let (if you use them), you want to set indent to 1 and set to resolve as let.

This at least gets the indentation working and gets symbols created in defnc and the if-let and when-let bodies handled correctly.

Main issue still is that Cursive really isn't aware of symbols bound by let inside of a cond, so finding usages and refactoring tools on those symbols won't work properly.

Are there other issues you've encountered?

[Engelberg]

Oh, and it's worth mentioning that you only have to teach it about indenting and resolution once, and then it remembers it across all projects.

[cyppan]

Do you still use it with Cursive? I'm trying to configure the editor to support it like you said but it appears there are two paths to better-cond.core/cond and Cursive by default chooses the clj-kondo one, which makes it show an error :

[Engelberg]

I don't currently use Cursive or clj-kondo. I'll need to reach out to @borkdude who supplied the pull request for better-cond to support clj-kondo to see if he knows why it is conflicting with Cursive. In the meantime, try going back to version 2.1.0, which is functionally identical but without the clj-kondo piece.

[borkdude]

I guess Cursive scans all the code in the dependency and discovers the clj-kondo hook that has the same namespace/name as the original, which is intended. Note that the clj-kondo hook is not loaded by clojure itself, there is no conflict there. Perhaps Cursive can be changed to not prefer code in a clj-kondo.exports directory. /cc @cursive-ide

[borkdude]

Btw, we can rename the clj-kondo hook name (in both the code and clj-kondo config), that's not a problem, if that helps to cause less confusion.

[Engelberg]

Would renaming the hook resolve this issue?

[cyppan]

Thanks for your answers, yes renaming would resolve the Cursive issue

[borkdude]

I'll make a PR

[borkdude]

See #20

[Engelberg]

OK, I pushed @borkdude's pull request as version 2.1.2. Hopefully this will provide a better experience on Cursive. Let us know how it works out.