Clojurians Log v2

I think it could add too much noise, but possible

The case of 1 usage would be interesting to me since in that case you could directly inline the binding value

Maybe you want a diagnostic for when only a single usage of a local?

A single diagnostic maybe

I could do this in clj-kondo but it's not always something you want to fix

So this is why I was thinking about LSP references

Yeah I get it

As a optional feature sounds ok to me

TBH don't think too many people would want this running by default

I think only showing it with 1 reference would be a better default

Also not a diagnostic, just a side info like references

I don't think so, lens are good for consistent UI, this is sounding to me more like a info diagnostic, something you wanna show to user but it's not a warning or error

that's why the diagnostic is called info

I think diagnostic is too intrusive for this, even info

Even only for 1 usage and optional?

I can first experiment with this in clj-kondo

I think it's a good idea to try

what do other language lsps do? like rust or java. do they say how many references a local has?

They don't

What rust does is show the type of the var which is awesome, I already thought how to apply that for clojure but not good or easy

Because there the type is optional and has a way to type of you want

Clojure doesn't has this syntax so it would look weird

Even if it showed number/string/list/vector/map that would be a good start. I've made mistakes a couple times because of the difference in behaviour for conj and list/vector.

yeah me too, the problem I saw with that approach was that it was incredibly noisy, but also type inference in a static analysis is not easy to do

> type inference in a static analysis is not easy to do this part is done by clj-kondo, clojure-lsp doesn't do any type analysis AFAIK

I'm a +1 to "let me know if this let-bind has only one use" btw.

@borkdude I know, it was for testing purposes

need to experiment again with that

testing purposes?

yes, I was testing if that feature would look like nice

ah ok

> I'm a +1 to "let me know if this let-bind has only one use" btw. Well I guess clj-kondo could make an optional linter for this

that you can set to :info

Also a lot of squiggles in destructuring. I guess :let and destructuring are cases where you can't avoid introducing bindings

yeah, beisdes that looks good

also in cases like:

(let [foo ...]
  (map #(foo %) ...))

I don't think that looks good at all

I think those are just false-positives to fix, besides that it's exactly what the feature is suppose to do, highlightth the local being used once

for example squigls in function args are another false positive

often introducing a local is also informative, giving something a name to clear up intent

yes, those need to be eliminated

but this is something kondo can't really do reliably:

(let [foo ...]
  (map #(foo %) ...))

so I'm already convinced this isn't a good idea

I've pushed this to let-binding-single-usage if anyone wants to play around with it.

yeah, also I do think using 1 reference or 1 reference only in place of squigles would make way more noiser than currently

One case that got me thinking was:

(let [x 1 y x] y)

(let [x 1] x)

code lens are cool, but we need to be careful to not add too much noise, var-definitions are good because you have few in a file

agreed

Is this something that plugins for your editor could do? Seems like all the information needed is there?

yes, clojure-lsp is such a plugin

but I already got it working and it's way too noisy, so ..

I don't really want clojure lsp dictating ui components in my editor. But an editor specific plugin could do all sorts with the information queried from lsp.

@ericdallo I have a branch with these ready for a PR. What's better for the PR? To be • based on my previous PR with extract-function, or • based on master so it can be applied independently?

cool! for sure separated!

Merged! great PR, thank you!

Oops, I went to push and noticed: - [ ] I updated documentation if applicable (`docs` folder) And that got me to thinking about the naming. They're named: • Change nested if to cond, and • Change cond to nested if right now. Is that good enough? Here's the videos of them working in emacs

they look great! the naming looks good too, I will happily review it soon

Prototype

that looks completely valid, I would use that code action :)

would be nice to provide the other way around as well, same we did for thread and unwind thread

and couple of more actions like that

Yup, working on the reverse now. It might also be nice to put in some enhancements so an if-not ... gets turned into a (not (... but I figure one step at a time.

makes sense

Filed https://github.com/clojure-lsp/clojure-lsp/issues/2171. If it's OK, I'll volunteer for it.