We created and maintain Calva - Ask us anything

[bpringe]

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!

[PEZ]

@rudolfvesely

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.

I think it is a good idea. 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.)

@rudolfvesely

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

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

[rudolfvesely]

@PEZ

file as a feature request on Github

Feature request: Jump back and forth between Clojure source and its test

Thank you.

@PEZ

I know many users are not ready to let structural editing take full precedence

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.

[PEZ]

@rudolfvesely

I’m not happy when editor deletes right bracket when I backspace the left one.

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

[rudolfvesely]

You’re right, that’s not Calva / not happening with Clojure code. I had this problem with a different language in VSCode and I don’t remember which one.

But interestingly enough, with "calva.keybindingsEnabled": true brackets are not deleted at all when I hit Backspace or Delete .

[PEZ]

@rudolfvesely

with "calva.keybindingsEnabled": true brackets are not deleted at all when I hit Backspace or Delete

Indeed. That’s by design. There is a button on the statusbar where you can toggle that behaviour. (Or just use alt+backspace/delete instead). Did you try the hijack and/or the Paredit Keymap settings I mentioned?

[rudolfvesely]

@PEZ

There is a button on the statusbar where you can toggle that behaviour.

That’s what that small lambda is for. Thanks! I should read rest of the documentation…

@PEZ

Did you try the hijack and/or the Paredit Keymap settings I mentioned?

5 min after I installed Calva for the first time I set "calva.keybindingsEnabled": false and I haven’t turned it back on yet. I like my editors to work the same way as gedit in GNOME 1.0 that I started using (I think) in 1999.

I need to force myself to switch it back on but I will do it .

Or I’ll just define that single key binding if that’s what you mean by hijacking Keymap settings.

[Phill]

Hi Calva crew!! I enjoy the tasteful rededication of ctrl-arrows. But I notice that my Calva in Linux uses c-a-. and c-a-, for slurp & barf respectively (the mnemonic being the > and < printed on the keycap), while my Calva in Windows uses ctrl-alt-right and ctrl-alt-left. Is one or the other missing an update?

[PEZ]

That is by design. I don’t quite recall the rationale, but generally it is often tricky to keep the same shortcuts across operating systems when it comes to keeping them simple to type. Slurping and barfing is different on Windows, Linux and Mac for this reason.

There is some context around the particular choices at this issue:

Change slurp, barf, forwardSexp and backwardSexp default keyboard shortcuts

[PEZ]

Let’s see if I can summarize the existing options for default Calva keyboard shortcuts, especially involving Paredit, especially Strict mode.

There is the nuke option: calva.keybindingsEnabled: false, as you have found. Then you are left to define whatever shortcuts you want for anything you want. You might want to tweak some VS Code defaults as well to make it behave more like Notepad.

Next nuke, a bit smaller blast radius; calva.paredit.defaultKeyMap: none. Then all Calva default shortcuts, except the Paredit ones will stay intact. Again you are left to define whatever shortcuts for whatever Paredit commands.

Next level, is to keep most Paredit shortcuts, but saying "no, thank you” to the help with protecting the structure from accidental deletes of brackets. The CaveMan mode of Paredit: calva.paredit.defaultKeyMap: original. Then you will probably also want to set calva.paredit.hijackVSCodeDefaults: false.

Calva defaults to calva.paredit.defaultKeyMap: strict, where the structure is protected, and there you need to press alt together with backspace or delete to make them just delete.

Calva also defaults to calva.paredit.hijackVSCodeDefaults: true, making some VS Code commands structural. For instance moving lines up and down is often resulting in something with a broken structure, so with this hijack enabled, Calva will instead drag sexpressions rather than lines. This hijacking will probably expand further, and also be used to make some Paredit shortcuts less hijacking (when the option is diabled).

There is also a setting for protecting from entering unbalanced closing brackets: calva.paredit.strictPreventUnmatchedClosingBracket. It is default disabled currently, but will probably get to be the default soon.

[rudolfvesely]

That’s a very good explanation. Thank you.

@PEZ

Calva defaults to calva.paredit.defaultKeyMap: strict,

I noticed that [λ] toggles calva.paredit.defaultKeyMap but I didn’t understand why it’s not doing anything. It’s not doing anything since I nuked everything by calva.keybindingsEnabled: false.

@PEZ

calva.paredit.strictPreventUnmatchedClosingBracket

Nice!

[Adama]

@PEZ

If you may? This is an AMA.

Calva is awesome. Thank you @PEZ

Could you please tell me is it possible to specify in a project created by lein to ignore all warnings in *_test.clj files? I checked Customizing Calva - Calva User Guide but I didn’t find such option. I also checked cljfmt but that’s probably not the right tool for such modification.

The reason I don’t want to see warnings (I’m assuming they can be described as code static analysis warnings) is that often I add tests for built-in functions like if-let. Not to test them but just to get understanding how builtin stuff works with different inputs and how for example my own if-something macro should work. The problem is that if I’m testing for example (if-let true 123) then I get warning that I should use when-let. And that’s absolutely correct suggestion but I don’t want to see it in _test.clj files since I do want to try stupid stuff there.

Thank you.

[PEZ]

Hello! I’m not sure what clj-kondo allows when it comes to disabling linting based on file names. Maybe the #_:clj-kondo/ignore marker would work for you? See clj-kondo/config.md at master · clj-kondo/clj-kondo · GitHub

[Adama]

@PEZ

Maybe the #_:clj-kondo/ignore marker would work for you?

This is actually better, I can be more selective. Thank you @PEZ

[rosswart]

@Phill

… I notice that my Calva in Linux uses c-a-. and c-a-, for slurp & barf respectively … while my Calva in Windows uses ctrl-alt-right and ctrl-alt-left. …

@PEZ

That is by design. … Slurping and barfing is different on Windows, Linux and Mac for this reason.
…

Has this changed in the last VSCode update (October)?
I am on Windows but now Barf Sexp Forward is c-a-. instead of c-a-right

[PEZ]

@rosswart

I am on Windows but now Barf Sexp Forward is c-a-. instead of c-a-right

I don’t know, tbh. The shortcut defaults in Calva are defined as such:

            {
                "command": "paredit.slurpSexpForward",
                "key": "ctrl+alt+right",
                "linux": "ctrl+alt+.",
                "when": "calva:keybindingsEnabled && editorLangId == clojure && editorTextFocus && paredit:keyMap =~ /original|strict/"
            },
            ...
            {
                "command": "paredit.barfSexpForward",
                "key": "ctrl+alt+left",
                "linux": "ctrl+alt+,",
                "when": "calva:keybindingsEnabled && editorLangId == clojure && editorTextFocus && paredit:keyMap =~ /original|strict/"
            },

Why your Windows VS Code picks up the Linux keybindings is very strange!

[mjmeintjes]

Same happened to me.

[avillega]

Hi Calva team. Thank you so much for all the effort and hard work, not only in Calva but in making Clojure more accesible to beginners with all the tools, docs, tutorials and videos. It is an amazing endeavour.

I have a question around highlighting. I know Calva uses its own fork of Clojure Warrior a bracket colourizer extension that is clojure specific. One of the main pain points for me when using Calva have been the highlighting features, I am not too much into highlighting and have found it difficult to consistently disable some of the highlighting features in Calva, it some times breaks, and some times is inconsistent. Given that VSCode now includes a default bracket colorizer that does bracket matching and highlights the identantion guides, does it make sense to remove the dependency on Clojure Warrior and use what VSCode is offering by default. Is there a feature that is not implemented yet in the default colorizer that is Clojure Warrior impeding such thing?

Thanks!

[PEZ]

Hi @avillega, thanks for the words of encouragements!

I would like to know what issues you have more specifically. Disabling Calva’s bracket colorizer should just work. As well as disabling the colorized indent guides. If it doesn’t, we should look into fixing that, and and an issue on the repository is welcome.

As for wether Calva Highlight does things that VS Code’s built-in doesn’t: Yes it does. These are the ones that I remember w/o consulting the code or docs:

1. Dimming of ignored forms (or whatever style you customize it to)
2. Italics for (comment ...) forms (or your preferred highlight style)
3. Colorize the tags/dispatches of tagged lists the same as the bracket color.
4. Highlight matched brackets at the tag for a tagged list
5. Option to display colorized indent guide for the active indent only

It’s hard to describe (and follow) from my lousy descriptions… Here’s a screenshot I made from the list:

The cursor is that light-blue bar before the #:g namespace tag. You can see that the corresponding brackets highlight and that the cursor is marked as being inside the blue #:b map (by the blue vertical guide).

I would love to not be colorizing brackets, at least as long as I don’t understand how to make it as mindbogglingly effective as the VS Code team has made it. However VS Code still does not expose its analysis nor the colorization to extension developers, so I can’t implement 3-5 based on that.

(Technically we are not using a fork of Clojure Warrior, btw. We are the official😀 maintainers™️ of what once was Clojure Warrior and the code is merged into the Calva code base.)