This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # asami (13)
- # babashka (14)
- # beginners (57)
- # calva (49)
- # cljs-dev (6)
- # clojure (98)
- # clojure-europe (28)
- # clojure-gamedev (3)
- # clojure-nl (19)
- # clojure-spec (4)
- # clojure-uk (39)
- # clojured (5)
- # clojurescript (39)
- # code-reviews (1)
- # conjure (4)
- # crux (4)
- # cryogen (4)
- # cursive (20)
- # data-science (4)
- # datalog (1)
- # datomic (16)
- # duct (3)
- # events (1)
- # fulcro (6)
- # graalvm (1)
- # graphql (1)
- # jobs (8)
- # jobs-discuss (19)
- # kaocha (2)
- # lsp (15)
- # malli (24)
- # missionary (6)
- # off-topic (21)
- # polylith (75)
- # releases (2)
- # remote-jobs (4)
- # shadow-cljs (42)
- # sql (35)
- # vim (10)
I agree that it's hard to know, but FWIW I think it's a good idea to err on the side of meeting people where they are, which would mean to default to behaving in ways they would expect based on their experience typing/editing in other environments.
*print-length* is nil, but long maps still get truncated. Is there something calva special that I need to adjust?
I often think of the people who never ask for help and wonder about what kinds of problems might be out there and how common without us knowing. I’ve worked with, and hav had longer and shorter coding sessions with quite a lot of people and use that as a way to learn about what people put up with. My experience is that people find it much harder to fix a broken structure than adapting to the help with protecting the structure. It might be extra much so with Calva, which relies on the structure a lot, though I am not sure about that, because LISP is what it is. The structure is part of the language paradigm.
We are squeezed between a rock and a hard place. We have made the choice to follow the Tao of LISP, adhering to its structural requirements. (And it is also part of the Tao of Calva to assume that people can adapt.) It causes some friction, which we try to mitigate in some different ways:
• When Calva detects that there is unbalance, it relaxes its strictness. There is a lot of room for improvement here, which we should close.
• We make it easy to force delete with the
• We make switching between strict and Cave Man mode as easy and discoverable as we can..
• We try to make it easy to select code in a structural way.
• There is a Fire up the Getting Started REPL command that early on highlights this structure protection. https://calva.io/getting-started/
Maybe you can make an experiment this year, @lspector? Instead of conditioning your students into thinking that structure protection should be switched off first thing, have them start by using the Getting Started REPL feature and see if they pick up enough from it to overcome the unfamiliar behaviour.
I’m thinking it’s more about learning to edit in a structural way than Calva itself and I’m finding that quite difficult. I guess it might pay in the end, but not using paredit or similar things before makes the experience a bit hard, maybe especially if you’re learning a new language like Clojure as well. Could be too much at the time. I don’t say that it needs to be changed, on the contrary, I think emphasis on structural editing is a good thing even it might not suite for some people. Personally I have not turned strict mode off and resort to option+backspace quite often. 🙂 I’ve learned maybe one or two shortcuts for modifying the structure, I don’t know actually how many I will need to be really productive. Also keyboard shortcuts tend to collide easily with other programs which makes using them even harder.
@pez I will indeed think about how to introduce this, maybe not saying "turn this off!" but instead noting that it is on, and that it can be turned off easily, and pointing out the switch button. I appreciate that the button is there and easy to use, but FWIW it took me a long time to re-find it even though I knew all about it before, in part because I forgot what it was called. It looks like it is also not mentioned on the Getting Started doc page.
My experience helping students to fix broken structures is that the key is to have them use an environment with good auto-reindentation and make sure they are invoking it whenever they have a problem. And rainbow brackets also help a lot.
A lot of things are not mentioned on the Getting Started page. 😄 The thing with
alt+backspace is mentioned in the Getting Started REPL guide.
@U023S3BQRFB it certainly a thing with colliding shortcuts in the mix as well. As for how many paredit commands you need, depends on who you are. I tend to use these a lot: • slurp/barf • raise • splice • drag-forward/backward • kill to end of list I also use some move commands like: • forward/backward sexp • backward/forward-up sexp
Found the mention of
alt+backspace . Pretty well buried! And if I understand correctly Windows users may not be able to get to that guide without jumping through hoops, right? FWIW I'd have it in the first paragraph of whatever getting started thing every new user will read, before they start to think that their keyboard has broken. I'd also include the pointer to the button for turning off strict mode there.
Also, in that guide (and anywhere else) it would be good to add to the mention of "Ctrl+Enter" something like ("or option+return on a mac"). Any friction on the path to "making it go" (and typing and editing) is particularly bad for new users. Mac users will look down, see no Enter key, maybe try control-return which does the wrong thing, then maybe if they are persistent finally find option-return, which works but they're not going to feel like they know what's going on.
ctrl+enteron both Mac and Windows. So if some Mac use tries
ctrl+return instead, that will work and do the right thing. I do think most people are smart enough to know that return and enter is the same thing. If not, they are going to have a hard time learning to code anyway?
About the Getting Started REPL on Windows, that is correct. There is a bug in Oracles Java install. We’ll work around it one of these days.
But if anything, that should be mentioned early in the docs. “If you are on Windows, Oracle’s Java will mot work.”
Regarding formatting your way out of broken structure. That doesn’t work in Calva, which needs the structure for ts formatting to work.
Ooo sorry for the confusion about
ctrl+enter above -- I see that it was really
Alt+enter that was in the docs, for which I had found that
option+return works. I guess you're right that
return is obvious enough, but FWIW I don't find
option to be automatic in my brain, and I suspect newcomers would appreciate an explicit note about this.
On formatting in a broken structure, alas I see that you are correct. Rainbow brackets work, but not re-indentation. I do rely on that in Cursive and other environments that I use, so that may prevent me from switching back to Calva (and save you from my incessant comments on beginner documentation 😀).
Haha, @borkdude! I am certainly excited about the questions we will get after the presentation. 😃 This is the talk we are talking about, dear Calva-friends: https://www.linkedin.com/feed/update/urn:li:activity:6805741678591258624/
Please don’t hesitate to connect with me on LinkedIn, folks. I have discovered that making it a network of a lot of Clojure heads made LinkedIn valuable and fun for me.
I hardly ever look at linkedin, but I do accept Clojure-related people as connections, except recruiters
I've started to prune my feed on there and am realizing I will like it more that way as well.
Yeah, because reasons I have tons of contacts on LinkedIn that do not add to the value. I am now trying to overcrowd them with Clojure folks. 😃
Also, folks: If you don’t think watching me make a fool of myself is enough to warrant attending clojureD, consider that you will also get to see @borkdude tell you how to make Your own fast, native Clojure scripting CLI with GraalVM and SCI!: https://clojured.de/schedule/#michielborkent
Will these videos be available afterwards (even for a price)? I'm going to be huffing and puffing my way up a big hill on Saturday
Hey folks 👋
I am having some trouble to run
clojure.tools.namespace commands when inside Calva repl (started by the jack-in command), I noticed the refreshes weren’t working properly, and when looking further I found that for some reason when inside Calva, it’s not loading the classpath correctly, eg:
When running from a vanilla
(clojure.java.classpath/classpath-directories) => ()
lein replin terminal, this return the correct classpath directories. Do someone has a clue on what can be going on?
I don’t have a
repl profile in my project, but I was starting Calva jackin with the same profiles I was using when starting from terminal.
I tried some other stuff and found out that when connecting to a vanilla
lein repl from terminal it returns the classpath correctly, but whe using the jack-in command sequence (with the nREPL middlewares) it stop getting the classpath correctly and returns an empty list
Yeah, that’s strange. I was thinking maybe you have a
:repl profile in your user directory, but it should be loaded automatically also with Jack-in, so that’s not what is going on.
When I try this I get:
Both in Calva and with
; Execution error (ClassNotFoundException) at java.net.URLClassLoader/findClass (URLClassLoader.java:435). ; clojure.java.classpath
I think that it is related with this issue actually: https://github.com/clojure-emacs/orchard/issues/103 I tried on Java 8 and it’s fine, just Java 11 has this problem
What is a good option for viewing clojure test failure diffs? In Cursive, there is a popup diff viewer. I tried configuring humane test, but it had no effect.
In my current workspace, the expected and actual outputs are being printed unformatted in
calva-repl. It isn’t easy to spot the difference in the failure.
The pretty diffs is my favourite feature of kaocha. There is also https://github.com/weavejester/eftest which does pretty diffs.
@sashton There's an issue about integrating test diffing with Calva: https://github.com/BetterThanTomorrow/calva/issues/1007. Please comment if you have anything you'd like to add.