Clojurians Log v2

I see. I'll make a not to make a case. Should be simple enough as I was processing a huge CSV file, so just need to get a public huge file and do it on top of that

Is there a calva specific way to rename a binding, so it knows what the scope is, not just a regular, global find and replace?

I think “Rename Symbol” setting in VSCode does that

Ah, excellent! I was just going through the calva commands. Thanks

hi! thank you for this super extension, it has helped me a ton working with Clojure in VSCode. i have had one issue that i've been unable to resolve regarding Calva Jack-In REPL and Figwheel Main, namely that i cannot get Calva REPL to connect. it gets stuck in ; Hooking up nREPL sessions... and all i can see in VSCode Calva Connection Log is Socket closed. i have tried this both with Jack-In and connecting to running REPL server (copied REPL dependencies to deps.edn and started app manually). i'm not sure what the problem could be related to, and i started learning Clojure just two months ago, so i might be missing a bunch of knowledge here. any pointers are much appreciated. 🙂

Hello. Glad Calva is of help! And sad that sad that jack-in fails for that project. Can you test with a fresh Figwheel Main project and see if you have the issue then? I should try it myself, but am tight on time right now. Also, describe your process for jacking in. What menus you get, what you select in them, and such. Maybe we can figure out what goes wrong easier then.

hi! i looked into generating a fresh Figwheel Main app from the template and it indeed worked as expected. i checked out the difference between it and my current project and noticed that i was launching the Calva REPL with alias that had :main-opts defined. as this was an "inherited" project i did not know that it could be removed and the build would still work when using Calva REPL, so i tried it and it did the trick! i now got the REPL working with my project. thank you for the help!

🎉

Returning to Calva after a long gap and excited to see all of the improvements!

Welcome back, @lspector! I’ve been missing you here. May I be curious and ask if you’ve just paused Clojure or if some other editor/ide worked better for you?

I've mostly been using Cursive, in part because I've also been using IntelliJ for teaching Java.

It seems that Calva has progressed a lot and I may switch back for my summer research students, who will be new to Clojure, and if I do I'll switch back for my own work since I like to use the same environment as my students.

FWIW we still don't agree about strict mode 😩. I was confused and stuck for about 1/2 hr yesterday before I remembered that that might be the problem, and re-figured out how to turn it off. I dig the humor of calling non-strict mode Cave Man in the docs, but FYI in my instructions for my students I will show them how to turn off "Infuriating Mode" (strict mode) before even evaluating their first expression 🙂.

Yeah, I remember we see this very differently. I’d like to propose that you try running with strict mode on a bit and use alt+backspace whenever you need brute force. It is really the major difference between strict and Cave Man that alt reaches over from one mode to the other.

But anyway, we have tried to make it easy to switch between the modes. There’s a button in the status bar for it even.

I do like strict mode being the default, but I wonder if we could/should notify the user better about the prevention of removing characters that would cause an unbalance (if this is what @lspector means is infuriating - if not, or if there's more, I'm curious). To elaborate on the above, we could pop up a notification on the first time backspace or delete moves past a character instead of deleting it, explaining that strict mode is enabled and this is why they just witnessed what they did. This message could have a check box to not show it again. Just throwing out ideas. I personally have not been infuriated by strict mode. 😄

We could consider renaming strict mode to Infuriating Mode. 😀 Only half kidding.

FYI the thing that sent me down the spiral of confusion this time was pasting in some unbalanced code from elsewhere (I didn't realize it was unbalanced), which led down a path that I would rather not relive in full detail 🙂. As I was beginning to figure things out I tried to change () to [] as I would in any other text editing environment and after a few seconds of fighting with it I remembered about infuriating mode. Then some googling and reading and I remembered about that little button on the lower left that can turn it off. At root I think is the fact that I interact with text editing in ways that strict mode wasn't designed for, and even if it tries to be more clever as @brandon.ringe suggests, it will always do confusing things that I don't want in many cases. I want it to show how brackets match and re-indent correctly, but aside from that I want it to act like any other text editor. My students, I'm pretty confident, will also have their expectations thwarted and that's bad news when they're also trying to learn Clojure, etc. And it's bad news for me even though I've been lisping since around 1985. But including instructions to turn this off in my first presentation and notes, etc., is a very small price to pay! So I don't want to make too big a deal of it.

Fair enough. > I want it to show how brackets match and re-indent correctly, but aside from that I want it to act like any other text editor. Does this happen with strict mode off?

I wonder what the majority of Calva users think about this (especially newcomers). I've seen very few complaints about strict mode being the default, and I feel it probably helps more than it hurts, but I could be wrong.

It mostly happens -- acting like any other text editor except for showing bracket matching and auto-reindenting -- with strict mode off. Closing brackets are still inserted and that's a minus rather than a plus, but it's not too hard to deal with.

There may be a bias in the feedback you see, because people who are thwarted at typing and simple editing are unlikely to hang around long enough to give feedback. If they already have programming experience, especially clojure experience, they may be fine or fine with figuring out how to turn it off. I think I may be in the unusual position of working with lots of people, over a long time who are coming from very different places.

And plus, for my own coding, the thwarting of my ordinary typing/copying/pasting habits is bad, but if I can turn it off I'll be fine.

> There may be a bias in the feedback you see, because people who are thwarted at typing and simple editing are unlikely to hang around long enough to give feedback. Indeed this could be the case more often than we know, but it's hard to know for sure, and either way we go we are making assumptions on some level. You bring up good points, though. I'm not totally sure what is best here, but I wouldn't want to change things too quickly based on assumptions (not that it's just up to me, of course). This is good food for thought, in any case.