Fork me on GitHub

Dear Calva friends: • Fix: • Fix: Thanks to @steffan for flipping a boolean and fixing a quite big problem, 1-bit leverage! Thanks to @jacob.maine for improving the clojure-lsp integration and carefully listening and sharing throughout the review process. 🙏 ❤️ calva

🎉 4
❤️ 1
calva 4

I had hoped to bring #joyride jack-in to this release, but will need some more hammock time on it. It is very special with starting a Clojure REPL running in the editor itself. 😃

👍 1

I think I noticed a not-super-important-but-slightly-annoying change in Calva this morning: When I jack-in, the output repl window is opened again in another tab group, even though I had it already open. My workflow is that I always have three tab groups, and I keep the output repl window pinned in one. So I always have it there, no need to open it again in another tab group 🙂 Was this indeed changed or is it just me?


There is no change that I know of that would cause this. Might be VS Code that has updated something, or just a glitch in the matrix. The API for this is less than stellar.


Haha ok sorry for my accusation then 😉


np at all! I am one to appreciate also some noise, because I've sometimes found signal there, when adding noise and signal over some time.

👍 1

VS Code's latest update modifies a number of settings. I just had to go in and reset a bunch of settings around indentation and bracket guides since the default behavior changed. They seem to be a bit cavalier about some aspects of people's workflows...


I feel them. Don't think they do such things without much consideration. But indeed, it can be quite disruptive.


Hi Calva friends, how to work on a project without a deps.edn file. My use case is, sometimes I want to write some adhoc script right inside a project. But I don’t want to define the deps.edn file.


My expected workflow is: 1. go to the working directory 2. create a random, say, x.clj file 3. open vscode, and vscode is able to jack in and calva works normally on that file.


I don't think jack-in supports it. Unless it's fine with Babashka or nbb.


Thanks for the info. Right, jack-in depends on deps.edn.


What’s your normal workflow on this?


I would do: 1. go to the working directory 2. create a random, say, x.clj file 3. clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version,"0.9.0"},cider/cider-nrepl {:mvn/version,"0.27.4"}}}' -M -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]" a. Note the nrepl port reported 4. open VS Code and do Calva: Connect to a REPL in your project a. Choose Generic project type b. enter port number at the prompt

thanks3 1

Or create a deps.edn with only {} in it and use


The steps are great!


A minor question. I only saw connect to a repl NOT in your project. It works fine. I wonder what’s the difference whether the repl is in or not in project.


No, it doesn't matter in this case. But that is because a bug where we don't find the nrepl port file. When that bug is fixed, you would loose some convenience-


If `Calva: Connect to a REPL in your project` means using the nrepl port file, then there shall be no need for me to manually enter port number at the prompt.


Seems something here can be streamlined is to leverage the nrepl.port file to auto supply the port in the calva prompt.


> But that is because a bug 😃


Another thing to confirm is, sounds like the generic or deps.edn project type really doesn’t matter. The only thing that becomes different is when we use deps.edn+shadowcljs, which controls how the cljs repl is connected.


With deps.edn project files calva reads the file to find aliases and such, so it matters a lot.


Right. Matters a lot.

Daniel Slutsky13:05:18

Hi. Args to Custom REPL Commands are so useful! 💜 We are using them as a way of passing custom information to Clojure tap> for the Clay tool. (the related discussion where we decided to explore the tap way:;cid=C17JYSA3H) Now, we still have a little problem. What we want One thing that seems a bit difficult is passing the code of the current form as a String to Clojure (rather than running it as Clojure code) -- e.g., if the current form is

(+ 1
then we would like to pass the string "(+ 1\n2)" to some Clojure function call, say the following snippet:
(let [__value (+ 1 2)] 
  (tap> {:code "(+1\n2)" 
         :value value})
(The reason we are interested in this is that we want to extract the code metadata on the Clojure side -- e.g. {:kind/hiccup true} if the code is ^{:kind/hiccup true} [:h1 "hello"].) Possible solution In general, generating the above snippet would require escaping of double quote marks, which is not easy. In Emacs+CIDER, the way we are currently handling it is by writing the code to a temporary file and passing the filename in the Clojure evaluated code. So, we would like the code snippet for custom REPL command to be something like:
(let [__value (+ 1 2)] 
  (tap> {:code-file "/tmp/clay-code-6tyapq" 
         :value value})
(where the text "(+ 1\n2)" is written into the file "/tmp/clay-code-6tyapq"). Could we do that in Calva? Any thoughts about how I could address this in Calva?


Not sure I follow. I can quote some code like so:

"calva.customREPLCommandSnippets": [
            "name": "Quote code",
            "snippet": "{:code (str '$current-form)}",
            "key": "q"
(+ 1
   2) <ctrl+alt+space q> => {:code "(+ 1 2)"}
We loose the newline. Is that problematic?

Daniel Slutsky14:05:45

Thanks! Oh, you are right, this way actually handles strings inside strings correctly, so there are no escaping problems. Losing the newline (since the code passed through the Clojure reader) is not a problem for the current need. The problem is that we lose metadata. E.g., for the following code:

(+ 1 2)

Daniel Slutsky15:05:30

Oh! (meta (quote $current-form)) actually returns the needed metadata. Thank you so much, @U0ETXRFEW!

🙏 1
calva 1


"snippet": "{:code (str \"^\"(meta '$current-form) '$current-form)}",
^:foo (println 1 "2")
{:code "^{:line 1, :column 23, :foo true}(println 1 \"2\")"}


Don't know if you've seen @U0514DPR7’s generous sharing of techniques around this, @U066L8B18. Here's a thread:

Daniel Slutsky15:05:30

Haven't seen that. So inspiring!

☺️ 1

Q: the .calva/config.edn file -- is that a user-level file or just a project-level file?


I'm not sure, actually. I have been assuming it is user level. Maybe @U02EMBDU2JU can shed some light.

Lukas Domagala11:05:40

Unless I misunderstand what you mean by "project/user level", it is project level. Every project would have it's only configs. We probably should add a way to have a user level version as well though


I think it would be nice to have user level config outside of VS Code's single settings.json file as an easier way to share dot files on GH for example. I understand the trade off is that such settings files wouldn't auto-sync across machines (which is certainly very convenient). Currently, I have my settings.json on GH but Calva config is just a part of that and I'd rather not have my Atlassian config on GH since it's purely work-related... and while that link is the main chunk of Calva settings, some of the others are intermixed further up the file with other stuff.

Lukas Domagala21:05:44

Yeah I can see your point. We still have to kind of decide where to go with the calva config. It was initially just meant for the new custem snippets and tooltips, but we could extend it to all the configs. At that point it would make sense to have a user level version. What's your opinion @U0ETXRFEW?


Losing the ability to sync settings across multiple machines would be a big loss -- but I think a lot of editors/plugins don't currently have that and rely on something like dot-files on GitHub for developers to keep stuff in sync. So... ¯\(ツ)


I think it might be a lot of extra maintenance for Calva development to have all Calva settings also available from config files.

Lukas Domagala21:05:47

Mhh, I think we could have that automatically generated. I'm more worried about confusion around merging configs in multiple files


It could be something for a Joyride init script to take care of. It would read some edn config file and write to the user settings. This would make the settings sync as well.


Part of why I asked is that I've been writing some pretty long REPL snippets and doing that in JSON which doesn't seem to allow multi-line strings is painful. (if I could write the snippets on multiple lines in JSON I'd be happier)


You can use Joyride to put those snippets in from the REPL. You could write the snippets as quoted Clojure code and then str that. And use vscode API for updating the snippets settings. I think. Haven't tried it. 😃


Also, for more complicated snippets it is often better to place a function in the the app and mainly call that function from the snippet.


This is for cross-project configuration that is not part of any app -- like my Clover config.cljs stuff.


> You can use Joyride to put those snippets in from the REPL. You mean Joyride can tell Calva to evaluate code?


Calva will eventually expose that as part of its API, but no, that's not what I meant. I meant using Joyride to stringify the snippets and, optionally, also to write the snippets to the settings.


You could stringify the snippets using any REPL, of course. But it fits quite nicely in with Joyride since you could also go for writing the snippets settings from there and also can save it as a Joyride script.


Ah, right, so write the snippets nicely as Joyride scripts and have it write them into the settings or whatever any time I change them? Kind of a nasty workflow but, yeah, I get it.


I thought more as rich comment things, more as a way to make it easier to write the snippets than when writing them as json strings directly.

Lukas Domagala02:05:16

Ah if it's "just" about snippets we would "only" have to provide a user level calva config.edn. That's an easier ask than having all config options available in the config.edn. @U0ETXRFEW you'd be happy with a user level config.edn? I'm not sure when I'd get around to it, since I'm busy with work and preparing my clojured thing, but it would probably also be a good "beginner" ticket.