Fork me on GitHub
#clj-kondo
<
2021-11-09
>
Chris McCormick09:11:14

truestory 4
❤️ 6
😆 8
mpenet15:11:06

is there a way to exclude an unused binding by name, regardless of ns (typically "this")

mpenet15:11:25

I want to avoid replacing by this or everywhere

mpenet15:11:35

and create giant diffs

mpenet15:11:45

(so via clj-kondo config would be better)

borkdude15:11:37

@mpenet currently not. this is all the config that is possible currently: https://github.com/clj-kondo/clj-kondo/blob/master/doc/linters.md#unused-binding If this is important for passing CI or git post-commit hooks, then you can turn that linter off for now perhaps using an extra configuration that you don't use in your editor. Feel free to create an issue about this.

mpenet15:11:11

I imagine that could be done generically for defrecord/reify/deftype etc bodies

mpenet15:11:31

:ignore-self-referencing-arg or something

FiVo17:11:48

Hey, I sometimes switch branches. Some namespace api changes and even after having evaled calling site as well as the changed ns, I am still stuck with unresolved var or some changed arity issue. I am using your flycheck integration. Is this a known issue?

Joshua Suskalo18:11:12

the easiest way to deal with this is to delete the .clj-kondo/.cache directory

Joshua Suskalo18:11:37

You could configure magit to do that automatically on checkout

borkdude18:11:03

Perhaps clojure-lsp will also fix that automatically by reindexing changed files (cc @ericdallo)

FiVo18:11:30

ok. So the current solution is the magit checkout hook?

borkdude18:11:15

or run clj-kondo --lint src on checkout

borkdude18:11:20

to update changed sources

borkdude18:11:06

which is probably better than throwing away your entire cache

👌 3
ericdallo19:11:43

this is a known bug on clojure-lsp side, we are currently ignoring didChangeWatchedFiles notifications from client which happens when user change the files outside the editor (using git for example)

ericdallo19:11:24

@borkdude that's related with my clj-kondo feature request of allowing to pass multiple input texts during lint I mentioned some weeks ago, I need to open the issue yet 😔

ericdallo19:11:12

from out DM: I found something to improve clojure-lsp performance during content changes that should fix some issues and I'd like to include not on the release of this week but on the next, but I found I can't make it work with current clj-kondo api the issue is that ATM clojure-lsp calls clj-kondo in 2 possible ways: • when analyzing external classpath or project sourcepaths, calling clj-kondo to scan a list of filenames • when any code is changed, calling clj-kondo with `:lint ["-"]` passing the buffer text as stdin I'm refactoring and improving the later, if someone change a git branch, or for some reason change multiple files multiple times, clojure-lsp call N times clj-kondo, making cpu go crazy obviously, I made some changes that will debounce and group these changes in a single clj-kondo call, but then I just found there is no way to pass multiple "texts" to clj-kondo 😅 I'd need something like:

:filenames ["a.clj", "b.clj" "c.clj"]
:lint ["text a", "text b", "text c"]
or wherever api you think it'd be the best, WDYT? Does that makes sense for you? borkdude  can you explain why you need to pass code + file names which aren't actually files? ericdallo  [9:43 AM] Because the code is not necessarily saved on disk, so we have only the text code and we need to know which URI that text was related borkdude  [9:43 AM] but where does this code come from? I don't understand the use case and would like to know more about it ericdallo  [9:44 AM] It's the code from the editor that was changed for example because of a git branch change borkdude  [9:45 AM] but why can't you just pass the changed file names in this case? ericdallo  [9:46 AM] Because they are not necessarily persisted on disk :/ [9:46 AM] They could be only on user buffer borkdude  [9:46 AM] I see yeah [9:47 AM] ok, can you make an issue? I'll think a little bit more about this. Is this blocking you?

ericdallo19:11:20

I'll try to create the issue later today

borkdude20:11:22

Yes, please do :)

borkdude20:11:39

It will also solve an issue I had recently. I worked around it by writing the inputs to temporary files ;)

ericdallo20:11:50

I see! alright, I should open the issue tonight, thanks!

borkdude14:11:50

Ah, the relief of tension...!

ericdallo14:11:39

hahah, sorry, kind of a crazy week 😅

borkdude14:11:38

No problem ;)