You can manually change the editor mode using the control in bottom-right corned of the editor. By default it will be something like Plain Text . If you click that, you can change it to Clojure (just for this editor) or configure the mapping for your extension (if you use something like *.bb). But as borkdude said, it might be a good idea to use .clj.

Great, thanks!

Not sure I follow. Do we need to change something in Calva?

Calva's setting for disabling linting uses the diagnostics middleware, so it disables all

(We have an issue to also use initialization options for that, but that's beside the point here I think.)

My primary "complaint" is just that I don't want to see the popup "Warning: you have clj-kondo installed", I will deal with the consequences myself

That should only show once for a user. Maybe it's not implemented that way, I need to check.

It's showing every time I open VSCode

Thanks. I'll look into it.

It might actually be good to remove it now. Issue and question for @pez here: https://github.com/BetterThanTomorrow/calva/issues/1091

Yes, I understand how calva does that ATM, my suggestion is just to rely on clojure-lsp config for that, because imagine some user wants to use a external clj-kondo linter but still wants to use the custom clojure-lsp linter at the same time

I see. Our reasoning for the Calva setting is that a user who installs Calva should be able to disable linting from Calva, because they might not yet know what clojure-lsp or clj-kondo are, and they shouldn't have to know if they just want to disable all linting (a user brought this up to us and it made sense). I think leaving the Calva setting, but maybe clarifying it would be good, like: "Show [all] linter warnings and other diagnostics"

Actually currently, by default, they can configure each tool independently if they want, AFAIK.

So long as you want Calva to show diagnostics, you would leave that checked, as it is by default, and configure clj-kondo and clojure-lsp as you see fit.

yes, I agree that a Calva setting is the perfect for the final user, my point is that every config on .lsp/config.edn can be configured via initializationOptions as well, so my suggestion is to have a calva setting where user could select what linters it should use from clojure-lsp. As of now we have 2, clojure-lsp unused-public-var and clj-kondo linter, https://clojure-lsp.github.io/clojure-lsp/settings/#diagnostics-linter. Otherwise that calva setting is disabling both linters, and users like @borkdude would not be able to use both clojure-lsp custom linter and external clj-kondo linter only via Calva setting, but manually changing clojure-lsp config

But is just a suggestion 😅

The only thing I asked for is to not have the popup about uninstall clj-kondo all the time. The rest I can deal with

yes, I know, is just that your question made me think about this possible case

I do want to see additional linters from clojure-lsp

in the lsp config I can do this right?

:linters {:clj-kondo {:level :off}
           :unused-public-var {:level :warning}}

doesn't this take care of it all?

yes, that's my point, user needs to know that this config exists and need to know about the third party lib that calva uses

yes

my suggestion is that the user could just change calva settings that would do that easily

but like I said, is just a suggestion, not a priority it seems 😅

> so my suggestion is to have a calva setting where user could select what linters it should use from clojure-lsp I don't understand. I think clojure-lsp should be configured in one place, not Calva and some other place

clojure-lsp can be configured via a file .lsp/config.edn and via initializationOptions passed from the LSP client when starting the server

from a final user point of view, I just want to configure it via my editor friendly Calva setting, not needing to know another lib that Calva uses that I need to change

isn't it better to prefer the .lsp/config.edn file so team members have to just configure it once and not in their own editors?

oh I disagree then :)

yeah, it depends on the use case

for teams, yes, for single users no

I still disagree though. Just write the docs one time and it works for all editors

Editing a .edn file is easy, no fancy UI needed

I don't want my config spread in some weird VSCode directory

or .emacs.d

I want to do it once and use it from both editors

yes, I agree it has benefits, I just think this is something that I like on VSCode, handle things for me. Maybe Calva could change the .lsp/config.edn

just like clojure-lsp now changes .clj-kondo/config.edn

it'd be the best of the options maybe

yeah, that would be better I think

Users are encouraged to share vs code settings via vcs though. That is not where the distinction cuts.

@brandon.ringe, the want to disable lint diagnostics surely must be quite uncommon. What if we just have that in our documentation that it can be configured via the lsp configs?

I agree

the time it was implemented that setting on Calva, clojure-lsp didn't have that option, now I think it make sense 🙂

Agree we can remove the warning that bugs @borkdude entirely now. Anyone who get the problem with double linting will have to find our docs. Which are not really hidden.

> What if we just have that in our documentation that it can be configured via the lsp configs? Adding something to the docs pointing people to the lsp config I think makes sense, but I see no reason to remove the Calva setting. By default all linting is enabled and anyone can configure things as they see fit with the tools' configs.

If you want to disable all linting without wanting to know what those tools are, you can uncheck the setting

It’s a setting too many in my book.

What I mean is, I see no problem here that needs to be fixed, aside from maybe pointing out the lsp config file in the docs and/or linking to the clojure-lsp docs. Maybe I misunderstand though. Btw, I'll remove that kondo warning.

I think the setting mostly causes confusion. Should I disable it here or here? What are the implications of the possible combinations? Etcetera.

I thought we discussed and agreed to this, along with the user who requested the setting in the past :thinking_face:. But, if you want to remove it now, we can. It might put us right back to someone else saying "how do I disable linting? Oh, I have to know this other tool is used by Calva and configure it even though I don't want linting? How do I configure that?" I don't know the best thing here though.

We may just need to remove it and point people to clojure-lsp docs when they ask. I just haven't really seen any confusion from users about the setting.

This thread is confusion. 😃

I thought you might say that, lol

I think we are talking about 0.001% of the users crazy enough to want to disable linting help.

Agreed

Removing is simpler, anyway

https://github.com/BetterThanTomorrow/calva/pull/981 Here's the discussion fyi, but I'm leaning on removal.

As I am adding an lsp setting the sum of zero is nice. 😃

Reread the discussion super sloppy, but I think one of the things there are about that it was a clj-kondo setting. Now it will be a clojure-lsp setting, right? So more direct.

Yes, things are different now than when we made that change

It will not be the first time we have threshed a bit. 😃

Prolly not the last either. Haha.

Made an issue to remove it. Hooray for removing things! 🎉 😄

That setting didn’t spark joy!

FYI: Run Current Test on the with-test macro does not run the test with this vsix, but it does in current Calva.

(with-test
  (defn foo []
    #{{:id           1010101
       :display-name "Campaign 1010101"
       :state        "enabled"}})
  (is (= #{{:id 1010101
            :display-name "Campaign 1010101"
            :state "enabled"}}
         (foo))))

With the above and the vsix, I get the following output:

; Running test: defn…
; No tests found. 😱, ns: 0, vars: 0

Added the above to the PR, maybe I should have just added it there to begin with :man-shrugging:.

Both works! 😂

Works well for me!