Fork me on GitHub
#cursive
<
2024-04-28
>
Eric Chua20:04:26

Like to ask, how can I resolve these issues in latest intellij + cursive (if not mistaken, generated by macros for hiccup).

cfleming10:05:08

I would have to add support for that, I’ll check that.

👍 1
genekim21:04:58

OMG. Showing # of usages inline, @cfleming — it’s so beautiful!!!

🎉 4
genekim21:04:18

Not to get histrionic or overly-dramatic, but I think this is going to be life-changing for me — I’m already imagining how many functions I can delete or start moving to different namespaces!

genekim21:04:40

I just upgraded to IntelliJ 2024.1, and saw this for the first time

cfleming23:04:35

Great, glad it’s useful 🙂

raspasov17:05:50

The best invention since Cursive itself! 😃

👍 1
raspasov17:05:33

Just curious, how accurate is the usage count in all situations? (I know in the past occasionally a symbol with a short common name could be incorrectly color-marked as to whether it’s used or not – I believe it was some sort of an IntelliJ internal indexing limitation @cfleming)

raspasov17:05:49

In any case, it seems very useful.

Anders Corlin19:05:09

Cool, I saw that too and wondered if it was new or if I hadn't thought about it before ... but then it's new 🍾🍾

cfleming20:05:22

The release notes had some details on the accuracy: > Like the Java implementation, this is a best-effort annotation. What that means is that vars with names that are very common appear in lots of places, and that makes the search very expensive for a (semi-)real-time annotation and they won’t be annotated. There was a bug previously which made this extremely conservative for Clojure, so it should work better now, but it’s still noticeable for vars with names which are words which appear frequently (so names like action, project and module in the Cursive source, for example). This means that this is generally useful for finding unused vars, but some will be missed if they have very common names. If an annotation appears, it should be accurate, though.

👍 3