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 
.
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?
That’s what that small lambda is for. Thanks! I should read rest of the documentation…
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.
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?
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:
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.
That’s a very good explanation. Thank you.
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.
Nice!
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.
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
This is actually better, I can be more selective. Thank you @PEZ
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
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!
Same happened to me.
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!
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:
(comment ...) forms (or your preferred highlight style)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.)
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.
