Is this about clojure-lsp/unused-public var?

I'm not sure. New to Calva... I have a namespace that declares functions that are only called in the REPL. So if possible I would like to disable all warnings like this

the docs for those are here: https://clojure-lsp.io/settings/#clojure-lspunused-public-var

the screenshot shows the linter name: clojure-lsp/unused-public var.

@UKFSJSM38 would it be an idea to change the default of this linter to opt-in?

I actually like this linter 🙂

ah ok, yes, it can certainly be useful :)

Worked, thanks!

I know there are people that prefer to disable, but from my experience it's really useful for most of the people

I find this linter both useful and annoying. I really wish it could be set in the ns macro, so it could 1. be disabled on-the-fly from namespace I am working on heavily, and 2. leave an easily discoverable record that it is disabled, so if I know not to expect it to work if I open that namespace later.

I don't know how viable that is. I opened an issue about this a while ago in the Calva repo, thinking it was Calva mishandling things. I think you described some inherent problem with the order things get loaded.

it might work but needs some testing, also, from my experience people tend to avoid those config in code but changing on config.edn

shouldn't this already work?

Yeah, not sure if clj-kondo is considering that for custom-lint-fn

It works when set from config file, but not when disabled locally from the namespace you want to ignore.

ok, maybe it can be made to work. I thought clojure-lsp already did something with namespace config

That issue already exists: https://github.com/clojure-lsp/clojure-lsp/issues/1453

Borkdude suggested changing the config, not the code

So turns out that issue is a dupe of mine. I thought I filed this in Calva, but it was in LSP. https://github.com/clojure-lsp/clojure-lsp/issues/900

His suggestion back then was also just to change the config. But I think there is meaningful value in being able to disable this linter locally for the reasons I listed above.

WDYT @U04V15CAJ?

yes

The 2 biggest use-cases I have for disabling unused-public-var are 1. Main API namespace of a library. 2. Namespace I'm working on heavily, where I am adding/deleting things rapidly. For 1, I want to disable it because almost everything is expected be unused. But then I also want that to be self-documented in the namespace. So when I open up the file, I immediately see the linter is off. For 2, I want to quickly add the setting within the file I am working in. Then delete it when I'm mostly done with my work, and let the linter check up on me again. The localized self-documentation is helpful here too, to help me remember to delete it.

Personally I don't use unused-public-var at all but just go by the 0 reference count or run carve

and yet it's the linter I get the most questions about here 😆

for 1: usually will be used if you have tests for that, like clojure-lsp.api for example

TBH I think you are the only one I know that relies only on lens for that @U04V15CAJ 😅 , most people find useful that your editor tell that someone forgot a public function which should be: changed to private or just removed

I found myself multiple times removing unsued functions because of that

I'm totally ok improving the linter, like checking for metas e things like that, and comparing with the past, it improved a lot IMO, I receive way less complains about it nowadays

Yeah. It's definitely helpful... but it's also like "I know! I know! Leave me alone. I'll get to that." Which is when wish I could quickly toss up a temporary config right there where I'm working to get some peace and quiet.

that's why it's a info, not warning or error linter

Like deprecated

I understand your thought, but it looks like a function you are creating and clj-kondo is telling about the unused argument because you didn't use yet :man-shrugging: it's the same thing

Yes. Being an info does help. I am able to choose a more subdued color and have ErrorLens not show the message inline. But there is still noise CV vying for my attention.

yeah, I find VScode error lens more verbose than only showing the message when you hover like emacs

Hovering requires mouse input

anyway, there is a code action to add a Supress this diagnostics

:thinking_face: By name, that sounds like a viable workaround. What does using that look like?

Can't remember right now how to trigger code actions in calva, but it's ctrl + enter or something

I mean at a high level, how would you use it with what expected result?

when you select that code action clojure-lsp adds that

for that specific linter, I'd be happy to include a supress unused at ns level

but for that, we need clj-kondo support like mentioned in the issue

Cool shortcut for an inline disable. 😎 Unfortunately brings us right back to the issue at hand. unused-public-var linter cannot currently be disabled locally. Must go in the config file. As is that would be a no-op. 😪

what about a code action to add a config to .clj-kondo/config.edn supressing that namespace ? more work/edn manipulation though but we have rewrite-edn to help

That helps only with the convenience factor on the front end. Still not documented in a way you can easily notice it, and still need to go to the config to re-enable.

Agreed, maybe we should support it in clj-kondo to make it work just like other linters

That would be excellent if you can. 👌

you can set fail-level on the command line to not fail on info level warnings. filtering you can also do using the edn output and a babashka script. I think an issue + PR to filter on a minimum level would be handy

for bb + clj-kondo: https://github.com/clj-kondo/clj-kondo-bb

> filter on a minimum level would be handy would report filtering be coupled to fail-level? e.g. something to the effect of

--fail-level error --filter-report (or --report-failures-only)

--fail-level warning --report-level error

Another alternative solution to my specific use case would be to always report everything but group by level, so I can easy eyeball what matters.

I think the second one would be the most flexible

we can have another group-by option, but at that stage you might as well just write a babashka script to make it do what you want