This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-02
Channels
- # adventofcode (153)
- # announcements (29)
- # architecture (6)
- # babashka (5)
- # beginners (197)
- # calva (71)
- # clj-kondo (27)
- # cljfx (4)
- # cljs-dev (33)
- # cljsrn (1)
- # clojure (52)
- # clojure-australia (5)
- # clojure-boston (1)
- # clojure-europe (38)
- # clojure-france (1)
- # clojure-hungary (5)
- # clojure-italy (1)
- # clojure-nl (19)
- # clojure-uk (5)
- # clojurescript (12)
- # conjure (4)
- # core-async (3)
- # cursive (22)
- # datalog (70)
- # datomic (32)
- # deps-new (8)
- # emacs (79)
- # events (2)
- # fulcro (15)
- # graalvm (15)
- # leiningen (2)
- # lsp (5)
- # minecraft (1)
- # nbb (1)
- # off-topic (37)
- # polylith (11)
- # re-frame (9)
- # reagent (1)
- # reitit (3)
- # releases (1)
- # reveal (2)
- # shadow-cljs (42)
- # spacemacs (1)
- # tools-build (4)
- # tools-deps (55)
- # vim (11)
- # xtdb (6)
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: https://calva.io/pprint/#configuration
@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?
(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})
example
;; => {: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.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]
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.
I’ve opened it here https://github.com/BetterThanTomorrow/calva/issues/1413 🙂
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?
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?
yes, I meant lein new <project>
With .228 (after the revert), I’m not having any issues
The wonk shows up as soon as I edit a file, but not before
and then once I edit, it’s permanently in wonk mode
(I do have a paren-coloring extension installed as well: https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2)
Is it a file with CRLF line endings, @calen.pennington?
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).
Failure:
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….
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.
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 https://github.com/BetterThanTomorrow/calva/issues/1409
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 ❤️
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.
Clojure’s reader treats this line as a comment
Specifically to allow this!
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.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
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.
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.
I found this extension and it works really well with calva/clojure-lsp: https://marketplace.visualstudio.com/items?itemName=usernamehw.errorlens
FYI: this is a small patch to store a Set of the operations that the REPL supports: https://github.com/marcomorain/calva/commit/188d1c700fbc76bdaf449c88b675a515f550af33 This might help us to make errors more clear to the user.