We created and maintain Calva - Ask us anything

It will soon be three years since Calva was first released. Back then it was not yet clear how important VS Code would become. It was rather the encouragement from the Clojure community that kept us at it, feature by feature, fix by fix. The VS Code Extensions Marketplace reviews and the repository stars collected, and the activity at the #calva Slack channel, all tell the story of a product that has been there, and will stay there, for the benefit of its users.


Somehow Calva has become a pretty decent Clojure development environment. It has happened from many, many small steps, mixed with some bigger leaps. The latter much thanks to Clojurists Together.

Assuming that The Tao of Calva does not answer all your questions: In waiting for the latest State of Clojure results to drop in, the Calva Team – since quite a while consisting of me and @bpringe – hereby make ourselves available to answer any questions you might have about Calva and the process of creating and maintaining it.


I started switching from Cursive to calva for some months now but I feel I’m not using it at its full potencial to be fare I haven’t had the time to study it in deep.

Thanks for such a great tool.

1 Like

Hi @PEZ and @bpringe ,
I’m not a Calva user (20 years and counting on Emacs, VSCode is not really my thing), but I’ve been following its development, and I wanted to thank you guys for the amazing effort you’ve put in, and especially how you’re constantly trying to make it accessible to new Clojure users. You guys rock!


You are much welcome!

1 Like

Welcome! It is such a pleasure to put in work in this community.

1 Like

Calva is awesome. I use it as my main environment. I am so thankful I didn’t have to learn emacs as well as Clojure when I started out.

I have three questions:

  1. Maybe this is a vs code issue, but is it really necessary to reset my keybindings every other release? It’s a bit annoying so now I’m just trying to learn the standard ones instead.

  2. I would like to control the execution enviromnent (i.e. PATH and JAVAHOME env vars) Because I like to try out different jvms and stuff. And honestly, now I don’t even know what is used. Where can I set this for Calva?

  3. When printing too much, jacking-in again is not enough and I have to restart vs code to get a ‘clean slate’ is there any way around this?

The integrated linter is very nice.

Windows Remote Desktop does not convey ctrl-alt-left/right. I notice that it is possible to choose Paredit commands from the palette if you know their name.

In Emacs, I know how to reevaluate each form in the current buffer: m-x cider-eval-buffer. Is there an analogous command in Calva?

1 Like

It’s not a VS Code issue as much as it is a multiplattform issue. Keyboard shortcuts are notoriously hard to get right. Impossible even. When I created Calva I wanted it to have defaults for most things, but I underestimated the shortcuts quagmire. That said we have not been changing default shortcuts very often. The last year I think it has happened once, and it was three or four shortcuts. It was after much consideration, but it still caused disruption. Can’t promise it won’t happen again, because when something is wrong, it needs to be fixed, but I do promise it won’t happen willy-nilly.

Not sure what you mean here. If you are using jack-in, then maybe the jackInEnv setting might be what you need? See Customizing Jack-in.

This is a limitation with us using a regular VS Code editor as output panel. We have on our todo to add some options for this. As the regular editor has many advantages, I am guessing most people will want to stick with that anyway. You might get away with just closing the output window and opening it again (ctrl+alt+c o). Otherwise there is also a Developer: Reload Window command that is slightly less of a nuke option than restarting VS Code.

Super happy to hear you are enjoying Calva! Keep the questions coming!

Oh, yes. It sparks joy! :star_struck:

I didn’t know that. Goes towards the point I made about multi-platform shortcut hell, earlier. Not good at all. However, VS Code also makes it easy to re-bind shortcuts. If you are on an English keyboard, I know people how are happy with using shortcuts for slurp and barf that involve the > and < keys. (I’m on a Swedish keyboard so not an option for me, did I maybe not mention that on top of the platform issues, there is also a huge variety of shortcuts that become unavailable when considering various languages and keyboard layouts…)

Currently there are only two options:

  1. Select AllEvaluate Selection
  2. Load file

The first one has the drawback that Select All doesn’t participate in the Paredit selection stack, so it is bit hard to get back to where the cursor was. I should probably fix that… Issue welcome.

The second one does a bit more than what you ask for, but often works for the purpose. I’d welcome an issue to add the command you ask for.

Also, there is almost a third way to do it. To create the command yourself using a Custom REPL Command, … but, no, I don’t expose the text of the current file there. I should. That is really easy to add. Issue please. :heart: (I will probably just do this, but it is always a nice feeling to being able to close user issues.)

You’re welcome! And thanks for the kind words. :grinning:

1 Like

Thanks, I’ll try reload window next time.

In bash I just use

export PATH=/usr/lib/jvm/java-16-oracle/bin/:$PATH
export JAVA_HOME=/usr/lib/jvm/java-16-oracle/

and I’m a repl with java 16 as jvm. (my usual one is openjdk 11)

I figured it was probably calva.jackInEnv. It was a bit finicky to get to work. ( I had some syntax errors that was not causing errors to be raised) but I got it to work now.

Not working (missing "'s):

// not working
    "calva.jackInEnv": {
        "PATH": /usr/lib/jvm/java-16-oracle/bin/:${env:"PATH"},


    "calva.jackInEnv": {
        "PATH": "/usr/lib/jvm/java-16-oracle/bin/:${env:PATH}",
        "JAVA_HOME": "/usr/lib/jvm/java-16-oracle/"

VSCode calls it “Developer” but I recommend everybody to remember that command and use it when something in VSCode doesn’t work. For example when new keybindings didn’t start working.

@PEZ Thank you very much for Calva. I love it. I wouldn’t use Clojure without it since VSCode (Codium in my case) is the only editor I want to use. THANK YOU THANK YOU THANK YOU ;-).

If I may one question, could you please tell me how does Calva work with clj-kondo? Recently I wiped and re-install all extensions and I realized that something changed since older version of Calva installed clj-kondo as “extension pack” but it seems that the current version 2.0.194 doesn’t need it and everything works like before when I had installed both Calva and clj-kondo.


You are welcome! :heart:

If you may? This is an AMA. :heart_eyes: Calva does this by way of clojure-lsp these days. @bpringe and @ericdallo, @snoe and @borkdude are the team behind this awesome thing in your favorite editor. I’ll be talking about it a bit at :clojureD in beginning of June, btw. Get your tickets now.


I too agree that Calva is fantastic. Thank you @PEZ

Is this also a place for feature requests? Or rather Github?

1 Like

I’d say it is. We take our feature request wherever we get them. Even if often we then ask for them to be filed at GitHub. My experience is that the requests on GH often improves if they are first discussed a bit.

If you like any of my suggestions, I’m more than happy to file it at Github. Thank you ;-).

First, I was very excited to see your name on open-vsx.org.

open-vsx is not just about open source enthusiasm. Either patched versions (VSCodium) or complete forks (code-server) can’t use official VSCode marketplace without braking MS terms so open-vsx is very important. Thank you.

I was very pleasantly surprised when I installed Calva and typed “calva” into Command Palette and saw all commands. Very impressive.

The only problem I had was default settings. I quickly realized that default Calva keybindings override classic key shortcuts like for example Ctrl+arrows. I don’t know how about other people but I use Ctrl+arrows all the time to move cursor. I understand that you want to make some features easy accessible but I don’t think that overriding Ctrl+arrows or Ctrl+shift+arrows is a good idea.

Luckily it was very easy to disable all bindings "calva.keybindingsEnabled": false so I didn’t have to disable one by one and I could enable just a few:

    "key": "alt+enter",
    "command": "calva.evaluateCurrentTopLevelForm",
    "when": "calva:connected && editorTextFocus"
    "key": "ctrl+alt+enter",
    "command": "calva.evaluateSelectionAsComment",
    "when": "calva:connected && editorTextFocus"

There is one great VSCode extension for Elixir that you might want to look at: Elixir Test

All it does is to jump back and forth between Elixir source and its test. In other words in Clojure it would jump between src/a/b/c.clj and test/a/b/c_test.clj and if the test file doesn’t exist it would create that file with the following content:

(ns a.b.c-test
  (:require [clojure.test :refer :all]
            [a.b.c :as t]))

This would be wonderful addition to Calva :wink:

Thank you @PEZ for giving me the chance to present my suggestions.

Hi @rudolfvesely . Thanks for this feedback! There have been discussions around the keybinding overrides in the past. Keybindings are unfortunately difficult to get right (Calva has many by default, and keeping similar actions mapped to similar combinations can make changing one cause a cascading effect of needing to change others), but we continue to tweak things if/when it seems good to do so.

The ctrl+arrows and ctrl+shift+arrows bindings should still move the cursor and select things, respectively, but they do so in more of a Clojure-structure-aware way, at least when the cursor is in Clojure code. ctrl+arrows actually used to slurp/barf, but of course this was jarring for some new users and we somewhat recently changed them to more closely map to the default VS Code actions. This still may not be desirable for some users though. I’ll defer to @pez for his thoughts on this.

That test feature sounds interesting too!

I think it is a good idea. :smiley: The non-structural norm is of course going to cause some friction doing this, but I don’t think that structural editing should take the back seat if it can be avoided.

That said, I know many users are not ready to let structural editing take full precedence, which is why there is a setting that I think you might have missed (because I think it might not be mentioned in the documentation, or at least not prominently enough, I don’t remember). calva.paredit.hijackVSCodeDefaults. See if disabling that give you back some of what you think should be the defaults. I think it can be applied wider, even, so if you try it and still find places where you think Calva is hijacking too much, file an issue about them and we can have a discussion.

Also if you mainly want to target Paredit shortcuts and not kill all Calva defaults, there is a setting ”Paredit keymap” which you can set to none. (Though hopefully the hijack setting will prove enough and you won’t need the two nuke options, we will see.)

Please file as a feature request on Github. Sounds great!

1 Like

Thank you.

Yes, I’m among those users. I can’t imagine working without syntax highlighting or without linter or without "editor.formatOnSave": true, like I did 20 years ago but I’m not happy when editor deletes right bracket when I backspace the left one. That’s too much, I feel like I’m constantly fighting it.

But I understand that most people do like it so it’s better that defaults work for them. Thank you @PEZ.

Interestingly enough, that is not Calva deleting the closing bracket. It is VS Code default behaviour. :smiley:

1 Like