Clojurians Log v2

Hi, how would one enable Calva’s editor functionality in a file that doesn’t end with .clj /`.cljs` /`.cljc` ? In my case I’m working on a babashka script and think the file ending is irrelevant, but maybe I’m missing a bit of best practice here 😄

@looveh I usually use .clj for bb scripts as well

Some people use .bb. Maybe Calva could activate Clojure mode for that as well

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.

Is there a way to turn off the warning from Calva about running the clj-kondo extension separately? I mean, I know what I'm doing, kind of

@borkdude I don’t think that warning should show if you have configured Calva to not provide lsp linting. If you have configured it like that and still get a warning, I think that’s a bug. Please file an issue.

@looveh, you can tell VS Code that it is a Clojure file. At the right side of the status bar there is a thing displaying the language ID. It is also a button. That said, what @borkdude said. And we should add .bb to the default extensions that gets treated as Clojure.

@pez So Calva reads from my ~/.lsp/config.edn ?

oh I see, it's a Calva config

Yeah, a Calva config. It should probably be named a bit different, I now notice.

Does it disable the warning for you?

Great, thanks!

@pez @borkdude we now have a custom public clojure-lsp linter (unused-public-var), I think @borkdude will not get that linter disabling via Calva. I mean, now we can customize the linter only via .lsp/config.edn now, this way one could disable clj-kondo linter via there but use the public one from clojure-lsp still

c/c @brandon.ringe

Dear Calva-friends. Can I get some help testing this fix to the command for running Current Test? ❤️ • VSIX: https://12412-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.184-1086-find-test-d6910e70.vsix • Issue addressed: https://github.com/BetterThanTomorrow/calva/issues/1086

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.)

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:.

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.

Both works! 😂

Hi all, I'm a little confused what happens in my setup especially regarding intellisense. I took the fulcro template and adjusted it a little so I can jack-in with deps.edn . This starts also the shadow-cljs part through:

:watch {:main-opts ["-m" "shadow.cljs.devtools.cli"
                               "watch" ":main"]} 

@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!

@alpox You might need to add some option there to let shadow know it should load cider dependencies.

@pez thanks for the response! That sounds like a rabbit hole I didn't touch yet 😄

> I also wonder how I can switch between those two REPL connections Is this regarding the REPL window? There’s a command named Toggle the REPL Connection (clj or cljs) used for CLJC Files (also a button in the status bar).

If you jack-in using shadow-cljs project type you’ll see the option used there for injecting cider dependencies.

The Toggle the REPL Connection changes from shadow-cljs' clj server to the shadow-cljs cljs connection while the server started from deps.edn is not touched however many times I toggle

> If you jack-in using shadow-cljs project type you’ll see the option used there for injecting cider dependencies. Where would these options appear? I'm still a bit green behind the ears with these options

I am not sure it works having a deps clj w/ a shadow-cljs cljs session. It used to work, but might have been broken…

In the terminal pane you can select the jack-in terminal where the jack-in command is executed.

Thats all I see there - it all starts fine and works, just the switch between the sessions doesn't work, and the cljs intellisense

If thats not intended to be working I guess i'll have to take that 🙂

I wouldn’t say it is not intended, but you are out on a bit of uncharted territory. 😃

But for intellisense to work in cljs, shadow needs to know cider is requested. So those main-opts need to specify that, I think.

And if you jack-in selecting the shadow-cljs repl type you will see what options might be needed.

Ah, ok thanks, I'll do some research on that (Even though I have no idea how these things hang together) maybe I'll find something 🙂

I know people are using Calva with Fulcro + shadow-cljs fullstack. Maybe we can get help from someone in the know about that.

There must be something else off on my side :thinking_face: I started only the shadow-cljs build alone which also uses the cider argument but intellisense doesn't even show up there

Can you evaluate cljs things through the repl?

Yes, I also tried (js/alert "foo") just to go sure its connected to an instance

Well, I guess I'll try this for some more time at the weekend, I don't want to steal much of your time for what could stay a toy-project

Two strange things there: 1. you don’t get cider-nrepl lookup help even though the repl is started with those options 2. clojure-lsp doesn’t give you lookup help.

If you can make the project public, I can have a look and see if I can figure it out.

Oh the intellisense while typing and with ctrl-space works. The hover hints do not :thinking_face:

So completion works. Hmmm.

The project is currently pretty much just the fulcro template (Im in the planning phase) but I can upload it to github if you'd like. Its really not something mission-critical though.

I’ll have a look tomorrow. I’m curious now.

😃

Alright 🙂 https://github.com/alpox/fulcro-test here you go and thanks for looking into this! 🙂

I am trying to push a new version of clj-kondo, including the vscode plugin, but I'm getting:

Cannot GET /api/releases/stable

should I update this part?

"engines": {
    "vscode": "^1.33.0"
  },

I don't remember seeing this. Maybe they have some server side issue right now?

This is the entire log: https://gist.github.com/borkdude/5cd0e78877fc5cb69eae37b4687419bd

It's pretty annoying since I'm in the middle of a clj-kondo release

I commented out vscode-install which was the non-working step I think

and just published without this, not sure if that works, but we'll see

I don't even know why that was part of the package.json, I just removed it and it seemed to work

Weird. I have not seen that before either. It does seem like a server issue.