Fork me on GitHub
Lukas Domagala01:12:33

while we are talking about repl formating: isn’t calva supposed to use zprint in the output? evaling a map thats just one line also produces one like in the output, but sorted. printing it with zprint also puts every pair into a new line


zprint is not the default pretty printer, but you can make Calva use it via a setting:

Lukas Domagala12:12:38

@U9A1RLFNV sorry, I was confused by: > Client side always uses `zprint`. now I tried setting the printEngine to “zprint” or “calva” and jacking again, just to be sure, but I still don’t get new behavior. here’s the relevant part of my settings.json:

"calva.prettyPrintingOptions": {

        "enabled": true,
        "width": 120,
        "maxLength": 100,
        "printEngine": "zprint"


Thanks. Can you describe in more detail what is actually happening and what is expected via example output?

Lukas Domagala16:12:56

(require '[zprint.core :as zp])
(def example {:this :is :a :test :it :is :only :a :test :foo :bar :baz :but :better :if :it :does :not :fit :on :one :line})
;; => {:a :test, :bar :baz, :but :better, :does :not, :fit :on, :if :it, :it :is, :one :line, :only :a, :test :foo, :this :is}
(zp/zprint example)
;; => {:a :test
 :bar :baz
 :but :better
 :does :not
 :fit :on
 :if :it
 :it :is
 :one :line
 :only :a
 :test :foo
 :this :is}
thats just a basic example taken from the zprint docs. when i disable pretty print the only thing that changes is that the map is not sorted anymore.


Hmm, please file an issue so we can track it there.

Lukas Domagala17:12:18

sure, thanks for the help and all the work!

❤️ 1
calva 1

Hi, I’m trying out vscode + calva + babashka, and if I try to evaluate forms that are not written well (e.g. with undefined symbols), nothing will happen and I don’t see any errors either. Is this intended?


Sounds like something is going wrong. Can you provide code for reproducing the issue? A full project may be more helpful, but we could start with just code.


On my machine I can just create an empty folder and then jack in > babashka in there to reproduce this... If I try to eval this form in the repl window nothing happens.


If I try the same thing in the bb repl in a terminal:

user=> (asdf)
Could not resolve symbol: asdf [at <repl>:1:2]


And the jack-in terminal is also empty


Which bb version?


I fixed something in 0.6.7, if you’re not using that, please upgrade


$ which -a bb
$ bb --version
babashka v0.6.7


I see the same behaviour. Also with nbb. I think this is on Calva, @UUKPL2T9C. Please file an issue.


There is some option for making bb output nrepl messages. nbb does it by default. And if you toggle on Calva: Diagnostics Toggle nREPL messages Enabled (or something like that) and paste the relevant chunks with some extra context in the issue, we will have some clues to work from.


Thanks! Can you also add the nbb/bb nrepl logs?


How can I get them? I’ve added the nREPL diagnostics logs.

Cale Pennington03:12:12

I just started up calva on a new lein project (just ran lein init), and I'm getting some odd behavior from calva. When I jack in, sometimes (usually only if the buffer is dirty), calva has syntax errors from the middle of seemingly arbitrary lines of code. These prevent me from evaling anything in the file. If I close and reopen the file, everything works until I edit it. It looks like this when it fails


Do you mean lein new <project>? I can’t seem to reproduce the issue. Does it happen consistently for you?


Can you try with v2.0.226 and see if it is something up with the new version?


Also, that syntax highlighting, is it wonky before you try to evaluate? Can you describe the steps until you see weirdness? What OS are you using?

Cale Pennington15:12:13

yes, I meant lein new <project>

Cale Pennington15:12:23

With .228 (after the revert), I’m not having any issues

Cale Pennington15:12:37

The wonk shows up as soon as I edit a file, but not before

Cale Pennington15:12:45

and then once I edit, it’s permanently in wonk mode


Is it a file with CRLF line endings, @calen.pennington?

Cale Pennington13:12:49

I’m using OSX, so I’d assume no, although I haven’t explicitly checked


If you have the project available, please check. I can only reproduce something similar with CRLF files (but also only in the output/repl window) so it might be two different bugs).


The VS Code status bar shows this by default, btw.

Cale Pennington03:12:55

The syntax highlighting gets all wonky, too


Alright, people, seems we do have some issues with 227 also affecting those who do not enable experimental features. If you see things like what @calen.pennington has there please consider helping me debug it. I can’t reproduce it yet. And for getting work done, downgrade to 226….

👍 1

Dear Calva friends: Calva v2.0.228 is now released, reverting the Parinfer experiments I’m too worried that the error that @calen.pennington reported above ^ is a problem with something fundamental in 2.0.227 to let it stay there. As it is unknown how many users would be affected, I rather have it zero while we continue to investigate. I urge you and beg you to please run with version 227 until you think you experience blocking problems with it (hopefully you won’t!) we need to be many people collecting clues now. Thanks in advance! ❤️


@U9A1RLFNV @U0K592YDP @U0DAFTH63 and anyone else that might have latest dev checked out. Please not that I have force pushed a revert to the commit where we merged @U0K592YDP fixes to test query. I am so sorry for the inconvenience! But it seems otherwise this parinfer problem would block other improvements.


@U9A1RLFNV please also note that published is still at the experiment, a commit ahead even. I published a notice on the Parinfer page about the revert. Let’s see if we can fix the issues quickly or if we’ll need to revert published as well.

Marc O'Morain08:12:48

I was having an issue with the backspace keybinding not working on dev last night.


I think I know what that could be about. And it is probably easy to fix. Those highlighting issues on @calen.pennington’s screenshot are super worrying though…


Please update this issue with any further info you might have, @U0K592YDP


Will you believe that I felt impaired just now when 228 was automatically installed and I didn’t have these new features anymore?


Please, please run with 227, @UGNFXV1FA! I know you’ve been testing all sorts of versions of it up till now and it has been super valuable. I promise not to let this setback knock this effort out. I’ll continue trying to figure it out. I had hoped I could spend the time on refining the Parinfer stuff, but that’ll have to wait.


I am @U0ETXRFEW no worries, that’s what I meant with the screenshot 🙂 I’m just encouraging you and saying that I can be patient ❤️

💪 1

Note to self: That description of the Parinfer feature needs revisiting.


I found that if I put a shebang line

#! /usr/bin/env bb
at the top of a .clj file, VSCode’s “Format Document” will stop working (aka does nothing), but “Calva Format: Format current form” still works. The file syntax is set to clojure. I’m wondering whether this a VSCode bug or a Calva’s? :thinking_face:


It’s Calva. Or, rather cljfmt probably doesn’t handle non-Clojure content very well. Can you test with cljfmt from the command line and see what it does? Could also be that newer versions than the one Calva uses handles it better. Regardless, we should be able to work around it. What does “Format current form still works” mean here? That you can format some form in the document still? Calva will only send the current enclosing form to cljfmt with that command, so the shebang won’t be a problem. However, using the command at the top-level of the document (between some top level forms) should also not work. Please file an issue with your findings.

Alex Miller (Clojure team)13:12:29

Clojure’s reader treats this line as a comment


This line in particular or #! lines in general?

Alex Miller (Clojure team)13:12:39

The latter - #! Is special cases to act like ;

👍 1

TIL. Very good to know!

Alex Miller (Clojure team)13:12:11

Specifically to allow this!

Alex Miller (Clojure team)13:12:09

So that should be a valid Clojure file


Right, I’ve also tried invoking cljfmt (which calva uses) manually and it seems to be fine with that file


This could mean that it is not a cljfmt issue. But also that it is an issue in the old version of cljfmt that Calva uses.


Okay, so it seems calva is using cljfmt 0.6.3? I tested manually with 0.6.3 and indeed

Failed to format file: test.clj
clojure.lang.ExceptionInfo: Invalid symbol: /usr/bin/env.
1 file(s) could not be parsed for formatting
So I think you’re right! 0.8.0 doesn’t have this problem.


Awesome. Then we know a way to fix it. 😃


Does the VSCode Calva Jack-in terminal window get logged somewhere?


Not currently. But I’m curious now about why you wonder. 😃


Well, the application I work on uses taoensso.timbre and this logs to output. In production and on our dev server this log is caught by supervisorctl. But, when I work locally the log gets spammed into the JackinTerminal which does not allow a full history. And I need some values that are flying by haha


Please file a feature request about it.


For now I think you’ll need to start the REPL yourself and tee out the log. There is a command for copying the command line that Calva uses for jack-in.

👍 1
Michael W15:12:07

On the output tab, to the right there is a drop-down, there are 2 calva outputs listed for me, Calva Says and Calva Connection Log


The Connection Log is a bit of a misnomer. Or, rather the way we use it is not complete. It only logs messages we get from the ClojureScript repl session while it is connected.


Calva says is a bit more of a general messaging log.


I found this extension and it works really well with calva/clojure-lsp:

👀 1
👍 3
Marc O'Morain22:12:18

FYI: this is a small patch to store a Set of the operations that the REPL supports: This might help us to make errors more clear to the user.

👍 1