Fork me on GitHub
#calva
<
2020-12-04
>
Janne Sauvala07:12:32

Hi Pez, I liked your “ClojureScript loves React Native” video on YouTube! Your vscode setup looked neat, what theme were you using?

pez07:12:25

I’m using GitHub Dark. It’s not perfect (themes never are, right? 😃 ) but it is the nicest one I’ve found. I think it might be as complete, or maybe even more complete, than the default dark one.

Janne Sauvala10:12:22

Thanks! That is true that themes are never perfect. I find myself changing those frequently when I got tired on my current one 🙂 I’ll try this one next

pez11:12:22

I think it is more complete than the default one, because it shows me bugs in Calva’s syntax highlight that I wasn’t aware of. 😃

Stefan11:12:26

I’m feeling more lazy than adventurous today, so I’m wondering if somebody else has already gotten Vlaaad’s Reveal working with Calva and Leiningen? I’m pretty sure it should be possible…. somehow…

pez11:12:02

I listened to the #defnpodcast with @vlaaad the other night. Got me super curious about trying Reveal out with Calva. Would love if someone added how to set it up to http://calva.io.

Stefan11:12:55

Indeed me as well 🙂

vlaaad14:12:29

You can just use reveal nrepl middleware

Stefan14:12:24

Yeah I read that, but I couldn’t find vlaaad.reveal.nrepl/middleware on Clojars so I’m not sure about the version number. And I also seem to run into the JavaFX thing where I apparently have a JDK8 without JavaFX, but that shouldn’t be too difficult to fix I guess.

vlaaad15:12:11

This middleware is a part of default Reveal distribution, not a separate artifact. Having Reveal on the classpath is enough to use this middleware

Stefan15:12:34

Ok so I just add reveal as a dependency and use that middleware. I’ll try, thanks!

vlaaad15:12:27

Exactly! No problem 👍

Stefan13:12:32

Ok I got it working. @pez I put this in my Leiningen project.clj:

:profiles {:reveal {:dependencies [[vlaaad/reveal "1.1.164"]]
                    :repl-options {:nrepl-middleware [vlaaad.reveal.nrepl/middleware]}}}
With that, normal jack-in (using this profile) should launch Reveal as well.

pez14:12:53

Awesome. Can i hope for a PR adding that info to http://calva.io? 😍

Stefan14:12:27

Beat you to it 😝

Stefan14:12:53

If you’re going to try this out using a tools.deps project, could you maybe add that to the doc page?

pez15:12:47

Oh, didn’t see the PR. Very cool. I suggested you add something about PR welcome to the deps section.

bringe20:12:20

Has anyone here had an issue with not being able to get env vars from Calva's repl? If I run clj -r I can call (System/getenv "MY_VAR") and see the value, but if I run that same line in Calva's repl (created by jackin), it returns nil

bringe20:12:54

Interesting.... it has something to do with cider-nrepl or its middleware. If I take the jackin command and modify it to remove cider-nrepl, then it works :thinking_face:

clojure -Sdeps '{:deps {nrepl {:mvn/version "0.8.2"}}}' -A:dev -m nrepl.cmdline

bringe20:12:03

Ok, if I remove just the cider-nrepl middleware it works..

bringe20:12:16

@pez Any idea here? I've set the env vars in ~/.bashrc, have restarted my shell/vscode/my computer. I wonder if I need to set them elsewhere.

bringe20:12:12

Update: If I copy the jackin command and paste it in a terminal and start the repl that way, with an unmodified jackin command, and then connect to it manually, I can get the env vars. Using the vs code jackin command directly though, I cannot. I wonder what about the jackin process is different that makes my shell's added env vars inaccessible.

pez21:12:16

Is your code started from the shell?

pez21:12:46

Your VS Code, that is. 😃

bringe21:12:13

That fixed it -_-. I had seen people have this issue before but forgot, because it hadn't happened to me yet 😄

pez00:12:35

I have this situation now, since upgrading to MacOS Big Sur. Totally annoying.

bringe17:12:38

Do you think this has something to do with how Calva is starting the repl? For example, I can start vs code by clicking the shortcut, without using the terminal, and copy/paste the jack-in command into the integrated terminal, then connect calva to it, and it works.

bringe17:12:00

It only doesn't work with the above start method when Calva issues the jack-in command itself

bringe17:12:38

What I'm saying is, maybe there's another way to run the jackin task that would give access to the terminal env vars? I wonder if this PR could fix it - https://github.com/BetterThanTomorrow/calva/pull/654

pez19:12:54

We really should finish that WIP PR. Unfortunately it can’t fix this issue. Whatever process we start from VS Code, it can’t inherit an environment that VS Code does not have.

👍 3
pez20:12:02

That’s so good. I can imagine how this is biting a lot of people.

eval-on-point21:12:28

Is the clojure-lsp branch close to being merged in? Very excited for that feature 🙂

calva 6
pez21:12:21

It’s quite a bit from being merged, @mitchell_clojure. But it is often quite useable for the non-picky user. 😃 You can help test it as we move along, Via VSIX of via running Calva in dev mode from the branch. If via VSIX: There is a VSIX built every time the branch is updated, If you are logged in on CircleCI, you should be able to pick the VSIX up from the links at the PR.

eval-on-point21:12:27

ooh might have to give it a go. Are those instructions somewhere I should have seen?

bringe21:12:54

@mitchell_clojure See here: https://github.com/BetterThanTomorrow/calva/wiki/Testing-VSIX-Packages I had typed out a message earlier about testing the vsix starting now, but I have a whole list of things that need to be tidied up before releasing. Things like duplicate hover content, Go To Definition showing two definitions because Calva is providing a definition via nrepl and then clojure-lsp is providing a definition - this results in a peek window opening because vs code thinks it's two definitions (each provides a different location, one next to symbol and one next to def).

bringe21:12:11

There are other things as well but it's a lot to type, which is why I stopped earlier and was going to wait

bringe21:12:00

But feel free to test and make sure nothing crazy is happening. A lot of these things are easy to fix, and I'll be doing so in the coming weeks.

pez21:12:19

That’s why I said “non picky” user. 😃

bringe21:12:40

Yeah, what I wanted to avoid is people testing and reporting all the things I know about, and then having to respond to each one lol

pez21:12:39

Maybe we can make the PR text show what to expect?

bringe21:12:13

I thought about it, but it will be so easy to fix most things I don't know if it's worth the time to write them up before then

pez21:12:15

A checklist of known issues, that when ticked of can be reported on, or some such.

bringe21:12:29

Once we release, if there are quirks then, I'd say that makes sense

bringe21:12:11

Hm... I will think on it though

pez21:12:22

Your call, @brandon.ringe, since you are driving this.

bringe21:12:03

I guess it depends on how far out a release can happen. I think I may fix some of the easy things next week and then create the shorter list

pez21:12:19

Anyway, for periods of times I have been running on the crude version I built when starting that PR. It is quite usable and the quirks do not overshadow the benefits from some of the nice things that cljoure-lsp brings.

bringe21:12:41

Indeed, I've been using the latest PR version today

eval-on-point21:12:00

Unsure. Related to this is that there is a "proof of concept" folder for VSCode integration in the clojure-lsp repo that is over a year old. It is definitely a red herring for other people like me who might be curious about progress

pez21:12:47

This will certainly not be a smooth easy task for @brandon.ringe. But that is why it is good that he is the one doing it. 😃

pez21:12:16

I think the PoC thing is not so relevant since @snoe’s focus is not VSCode. But our focus is.

bringe23:12:03

Yeah, once we merge our client usage, we can submit a PR to update clojure-lsp's readme to point to Calva as a vs code client