Clojurians Log v2

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

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.

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…

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.

Indeed me as well 🙂

You can just use reveal nrepl middleware

https://vlaaad.github.io/reveal/#nrepl-based-editors

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.

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

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

Exactly! No problem 👍

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

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

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

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

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.

https://github.com/BetterThanTomorrow/calva/issues/859

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

Is your code started from the shell?

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.

Your VS Code, that is. 😃

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

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

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

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

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.

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

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

Also see here, @mitchell_clojure: https://github.com/BetterThanTomorrow/calva/wiki/How-to-Hack-on-Calva

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

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

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

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

Hm... I will think on it though

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

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

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.

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

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

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

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

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