Fork me on GitHub
#calva
<
2021-03-31
>
Niclas08:03:54

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 😄

Tomas Brejla09:03:51

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.

borkdude08:03:58

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

👍 1
borkdude08:03:31

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

borkdude09:03:54

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

pez10:03:44

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

pez10:03:11

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

Niclas10:03:46

Great, thanks!

borkdude10:03:39

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

borkdude10:03:07

oh I see, it's a Calva config

pez10:03:25

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

pez10:03:37

Does it disable the warning for you?

ericdallo13:03:24

@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

pez16:03:13

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

bringe16:03:28

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

bringe16:03:57

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

borkdude17:03:01

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

bringe17:03:42

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

borkdude17:03:07

It's showing every time I open VSCode

bringe17:03:32

Thanks. I'll look into it.

bringe17:03:16

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

ericdallo17:03:17

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

bringe17:03:39

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"

bringe17:03:28

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

bringe17:03:13

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.

ericdallo17:03:50

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

ericdallo17:03:03

But is just a suggestion 😅

borkdude18:03:03

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

ericdallo18:03:53

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

borkdude18:03:15

I do want to see additional linters from clojure-lsp

borkdude18:03:01

in the lsp config I can do this right?

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

borkdude18:03:17

doesn't this take care of it all?

ericdallo18:03:13

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

ericdallo18:03:32

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

ericdallo18:03:07

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

borkdude18:03:26

> 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

ericdallo18:03:54

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

ericdallo18:03:06

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

borkdude18:03:12

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?

borkdude18:03:22

oh I disagree then :)

ericdallo18:03:31

yeah, it depends on the use case

ericdallo18:03:45

for teams, yes, for single users no

borkdude18:03:33

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

borkdude18:03:42

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

borkdude18:03:13

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

borkdude18:03:22

or .emacs.d

borkdude18:03:32

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

ericdallo18:03:58

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

ericdallo18:03:06

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

ericdallo18:03:14

it'd be the best of the options maybe

borkdude18:03:16

yeah, that would be better I think

pez18:03:26

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

pez19:03:46

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

👍 1
ericdallo19:03:34

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

pez19:03:04

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.

👍 2
bringe19:03:11

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

bringe19:03:03

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

pez19:03:14

It’s a setting too many in my book.

bringe19:03:17

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.

pez19:03:10

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

bringe19:03:24

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.

bringe19:03:24

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.

pez19:03:07

This thread is confusion. 😃

bringe19:03:56

I thought you might say that, lol

pez19:03:14

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

bringe19:03:14

Removing is simpler, anyway

bringe19:03:31

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

pez19:03:42

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

pez19:03:27

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.

bringe19:03:48

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

pez20:03:45

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

pez20:03:04

Prolly not the last either. Haha.

😄 1
bringe20:03:08

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

clj-kondo 3
pez20:03:50

That setting didn’t spark joy!

😂 1
pez16:03:02

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

bringe16:03:00

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

bringe17:03:22

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

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

bringe17:03:49

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

pez18:03:57

Both works! 😂

bringe00:04:49

Works well for me!

alpox18:03:20

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"]} 
Now if I connect my repl to the shadow-cljs build through Connect to a Running REPL Server in the Project everything works (I have the repl etc.) but intellisense only works for the clj files. I also wonder how I can switch between those two REPL connections as it now only switches whenever I evaluate something in either a clj or cljs file. Is there a command I don't know about?

pez20:03:07

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

alpox20:03:25

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

pez20:03:27

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

pez20:03:08

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

alpox20:03:24

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

alpox20:03:11

> 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

pez20:03:21

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…

pez20:03:15

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

alpox20:03:48

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

alpox20:03:02

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

pez20:03:28

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

pez20:03:31

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

pez20:03:06

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

alpox20:03:25

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 🙂

pez20:03:33

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

alpox20:03:38

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

pez20:03:15

Can you evaluate cljs things through the repl?

alpox20:03:44

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

alpox20:03:28

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

pez20:03:30

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.

pez20:03:19

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

alpox20:03:34

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

pez20:03:55

So completion works. Hmmm.

alpox20:03:12

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.

pez20:03:22

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

alpox21:03:25

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

calva 1
borkdude21:03:32

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

Cannot GET /api/releases/stable
when executing vsce. Does this sound familiar to anyone?

borkdude21:03:24

should I update this part?

"engines": {
    "vscode": "^1.33.0"
  },
@pez @brandon.ringe?

pez21:03:26

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

borkdude21:03:17

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

borkdude21:03:21

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

borkdude21:03:30

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

borkdude21:03:43

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

bringe22:03:52

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