If you open up your extensions in VSCode you should see a settings icon for Calva bottom right. You can use that to manage when an extension is enabled. For example, you can enable / disable an extension for all your workspaces or per workspace. I had the same issue so I now I enable Calva per workspace.

Thank you!

Hi! Happy you like Calva! In addition to what @U0D6971L3 says: Calva shouldn't start unless there are Clojure files in the folder opened. If that happens anyway, we might have a bug. Regarding the the files created, I add .cache/ to my .gitignore so that I don't have to keep removing those directories.

I also remember opening my golang project, and having these directories, could be a bug

If anyone can provide a repro case and an issue, that would be appreciated.

In my case it starts Calva even when I open VSCode in an empty directory. In case you have any pointers where I should start looking in the Calva code, I could try and see if I find the issue.

That definitely shouldn't happen. This behaviour is defined in the extension manifest (`package.json`) like so:

"activationEvents": [
    "onLanguage:clojure",
    "onCommand:calva.startStandaloneRepl",
    "onCommand:calva.startStandaloneHelloRepl",
    "onCommand:calva.startStandaloneCljsBrowserRepl",
    "onCommand:calva.startStandaloneCljsNodeRepl",
    "onCommand:calva.calva.startJoyrideReplAndConnect",
    "onCommand:calva.jackIn",
    "onCommand:calva.startOrConnectRepl",
    "onCommand:calva.connect",
    "onCommand:calva.connectNonProjectREPL",
    "onCommand:calva.convertJs2Cljs",
    "onCommand:calva.convertDart2Clj",
    "workspaceContains:**/project.clj",
    "workspaceContains:**/shadow-cljs.edn",
    "workspaceContains:**/deps.edn",
    "onDebugResolve:type"
  ],

I found some https://github.com/microsoft/vscode/issues/37918 https://github.com/microsoft/vscode-java-debug/pull/196 that indicate that onDebugResolve:type could indeed have such an effect, but I don't yet understand it well. I also found out that Calva only starts up automatically when I also have the Joyride extension enabled. Once I disable it, Calva does not start automatically.

Thanks for researching, @U03M8C02BHS. Can you add an issue on Calva where we can track this?

Yes, I will create an issue.

I actually suspected Joyride a bit, but I have it enabled myself and do not see this behaviour. Could be that a difference in our respective user_ctivate.cljs scripts can give us some more hints. I see this in my-main:

...
  #_ ; <- remove this to un-ignore
  (-> (vscode/extensions.getExtension "betterthantomorrow.calva")
      ;; Force the Calva extension to activate 
      (.activate)
  ...

If I enable Joyride and disable Calva, Joyride will start automatically when VSCode is opened in an empty directory. Perhaps I should create the issue on Joyride then.

That's expected behaviour from Joyride.

So Joyride should start unconditionally?

I see.

Yeah, it needs to start in order to be ready to script VS Code regardless of folder opened and such.

However, I am now getting

ERROR: Run Failed: user_activate.cljs Cannot read properties of undefined (reading 'activate')

;; Force the Calva extension to activate 
      (.activate)

Maybe you have removed that ignore marker and are actually trying to force activate Calva?

Or, you happened to install Joyride when the user_activate script didn't default to commenting it out...

This is with the standard installation of Joyride and Calva, I didn't edit anything. Here is the issue: https://github.com/BetterThanTomorrow/calva/issues/1830

Aha ... my user_activate.cljs instead looks like this:

(-> (vscode/extensions.getExtension "betterthantomorrow.calva")
      ;; Force the Calva extension to activate 
      (.activate)

#_ ; <- remove this to un-ignore

Yeah. There we have it. This issue is fixed for new Joyride installs, but for existing installs it needs to be fixed manually. If you haven't edited the script at all, you can delete it and Joyride should install the updated script.

A reinstall did not fix it. In the latest release the #_ still isn't in there: https://github.com/BetterThanTomorrow/joyride/blob/v0.0.15/assets/getting-started-content/user/user_activate.cljs

Ah, then an issue in Joyride is welcome.

I created an https://github.com/BetterThanTomorrow/joyride/issues/84. For now I have changed the file locally.

Once the file exists Joyride won't update it. (In case that was not clear yet.)

I know.

https://clojurians.slack.com/archives/C03DPCLCV9N/p1660668013589339

Hello! Regarding dots vs slashes. java-time.format is a namespace, so it shouldn't be used as java-time/format, or am I misunderstanding your question?

Mhh, then I am seriously confused by this example straight from https://clojure.org/guides/deps_and_cli

(ns hello
  (:require [java-time :as t]))

(defn time-str
  "Returns a string representation of a datetime in the local time zone."
  [instant]
  (t/format
    (t/with-zone (t/formatter "hh:mm a") (t/zone-id))
    instant))

Yeah, maybe I am confusing things. Let me check it closer.

It seems that the module java-time.format defines a function format. That function is imported into java-time, if I’m not mistaken

So, it seems the use of the macro potemkin/import-varskind of makes it hard to inspect the namespace 😞

(ns-publics 'java-time) => {}

I'm sorry for adding to the confusion. There is both the namespace I mentioned and the function you mentioned. I just tried this a bit. Without potempkin I get the namespaces completed for something like java-, and reach the symbols in java-time using java-time/. And I can complete t/ using the alias in the example. However, import-vars seems to trip things up, as you've found. Maybe a structure like the one suggested by #polylith can be used instead? It adds some boilerplate, but is generally pretty nice.

@U0ETXRFEW Sorry, seems to be my mistake. If I evaluate the file so that the required namespaces are actually evaluated, then I also get the function completions like java-time/format. However, if I do not evaluate the file in the repl, then I will only get the completions for the namespaces. This is probably due to it being analyzable statically, I suppose. Thanks for looking into it

Makes sense. When a REPL is connected you get dynamic completions. Sounds like the static completions is lacking a bit here. Maybe something to bring up in #lsp.

Where is the edn coming from? Is it a result of an evaluation or copied from somewhere into your editor?

If it’s a result you can enable pprint to see it pretty printed (see the bottom status bar -> pprint button). If it’s some long edn you copied from somewhere, you could call clojure.pprint/pprint on it. You could also use the command to evaluate and replace the result in the editor with the call to the pprint function and then you’ll have it in the editor (if that’s what you want).

We probably should consider adding a command to Calva that can pretty print the current form without using the REPL. Calva's pretty print function does not evaluate stuff, and can thus be used for EDN/Clojure data which pprint via the REPL croaks on.