Fork me on GitHub
#lsp
<
2023-10-11
>
magnars10:10:03

Out of curiosity, what enables clojure-lsp to be able to lint unused public vars, that is beyond the scope of clj-kondo ? 🙂

borkdude10:10:26

Clj-Kondo provides the data upon which you can build additional linters

☝️ 1
magnars11:10:56

Am I understanding correctly that clj-kondo has all the necessary information, but :unused-public-vars is not wanted along with all the other linters of clj-kondo?

borkdude11:10:40

@U07FCNURX clj-kondo doesn't run as a server process and as such it doesn't have an overview of your whole project at one time, so it's hard to keep track of unused public vars that way. but it does provide the information necessary for more project-focussed tools that run as a server or a command line tool, like clojure-lsp or https://github.com/borkdude/carve

borkdude11:10:09

clj-kondo could do this but it would only work when you would say: clj-kondo --lint dir and then it would tell you the unused public vars from the directory

borkdude11:10:14

but this wouldn't work in the editor

magnars11:10:31

Thank you, that makes sense. 🙂 🙏

borkdude11:10:01

You can read about the info that clj-kondo provides here: https://github.com/clj-kondo/clj-kondo/blob/master/analysis/README.md

magnars13:10:20

I see that `clojure-lsp/unused-public-var` already has quite a few exclude -options, but here's a question about another one: Any way to not lint this when used inside a (comment -block?

(comment
 (def just-testing-some-stuff ,,,))

☝️ 1
ericdallo13:10:26

we don't have options for that but sounds like a good improvement indeed, @U04V15CAJ do we have any way to know if a elemnt is inside a comment? otherwise that may affect performance check each unused-public-var if it's inside a comment

borkdude13:10:48

clj-kondo does have this information internally, but not sure if it's exposed through the analysis

ericdallo13:10:01

I don't think it is, I think would be a good idea

borkdude13:10:18

@UKFSJSM38 since you create call hierarchies in lsp, don't you already have this information actually?

ericdallo13:10:15

no, we don't have rewrite-clj nodes available in the analysis to know that, only kondo analysis, we parse rewrite-clj nodes only when we really need it, and we don't need to know call hierarchy

borkdude13:10:00

I thought you derived the hierarchy from the kondo analysis

ericdallo13:10:46

yes, that's how it works when you call call hierachy, we check the kondo analysis, but not rewrite node

borkdude13:10:28

yes, so why not check kondo analysis when you need to know if some call happened inside a comment

borkdude13:10:32

and then your linter can act on this

ericdallo14:10:40

but if we don't have comment in analysis we can't do that right? that's my suggestion, to include in clj-kondo analysis

borkdude14:10:06

I think we have a communication problem. I'll try again later

😂 2
borkdude14:10:05

gotta do some groceries now ;)

borkdude14:10:34

my point in short is: you have the information you need, else you wouldn't be able to create these call hierarchies. just use that information for your linter.

ericdallo14:10:58

I don't get it why call hierarchy is related to inside-comment? analysis, my point is, checking a var-usage there is no way to know that var-usage is inside a comment without checking for other var-usagesof that ns + comparing locs to know if it's inside of that comment, or parsing rewrite-clj nodes of that ns.

borkdude14:10:18

you don't need to parse rewrite-clj nodes

ericdallo14:10:29

yeah, that's an alternative

ericdallo14:10:56

the most viable is to compare locs of a comment var-usage to know if current element is inside it

borkdude14:10:58

no, you DON'T need. it's happened several times now in this thread that you seem to be saying the exact opposite of what I would logically expect :)

ericdallo14:10:06

but do that for each unused-public-var may be a performance issue

borkdude14:10:10

hehe, now I really have to run

borkdude14:10:41

> the most viable is to compare locs of a comment var-usage to know if current element is inside it indeed, that seems pretty reasonable to me

borkdude14:10:02

public vars should be relatively low in number

borkdude14:10:09

unused ones I mean

ericdallo14:10:17

no, they are not, we already had a lot of performance issues with that linter

ericdallo14:10:30

include a :inside-comment? field on only var-usages that are inside a comment seems to be an option that affects less performance IMO

borkdude14:10:18

what is next: inside-defn , inside-my-custom-namespace/foobar , adding a field for every "inside this or that" would get things a little bloated.

ericdallo14:10:47

comment seems to be a specific case, but I got your point

borkdude14:10:22

For the 1000 public vars, you will maybe have 10 or 20 unused public vars, doing the extra location check only for those candidates, how would that affect performance badly? I have a hard time imagining that. but now I really gotta run

ericdallo14:10:15

we can do a test with a big repo but knowing how complex is that linter already, I suspect it may happen a performance issue

👍 1
borkdude15:10:56

@UKFSJSM38 this is the internal representation that clj-kondo has of a so-called "callstack":

$ clj -M:clj-kondo/dev --lint - <<< '(comment (def x. 1))'
([clojure.core def] [clojure.core comment])
x.
linting took 49ms, errors: 0, warnings: 0
When you define a var, the first element is def and then comment - this format is only used internally so far, but could perhaps be exposed (probably as maps though, instead of vectors)

ericdallo15:10:19

yes, that would be very helpful

ericdallo13:10:55

Done! available on the latest nightly #C032YH7P0R2

🎉 2
anders13:10:37

I'm making use of :paths-ignore-regex to remove paths I don't care to be analyzed. However it does not seem to be used for filtering which directories will be watched. Is there any way to control this via a configuration parameter?

ericdallo13:10:41

the watch configuration is completly done on client side (editor), for emacs lsp for example there is the lsp-file-watch-ignored-files and lsp-file-watch-ignored-directories

❤️ 1
magnars14:10:25

@U0ESP0TS8 this means you can add your own directories like this:

(add-to-list 'lsp-file-watch-ignored-directories
             "[/\\\\]\\.git\\'")
There's a whole bunch of escaping going on, courtesy of emacs lisp regex shenanigans, but if you squint, you can see where to add your directories. 😅

😂 3
❤️ 1