Clojurians Log v2
joyride
Dear Joyride friends: Latest Calva uses ^ that ^ API to implement Joyride Jack-in. Here's a video showing the process from not having the Joyride extension installed until you are scripting VS Code itself. 1 minute 7 seconds, including me flailing around a bit.
I'm looking at adding init scripts. When developing VS Code extensions you need to implement an activate(context: vscode.Extension) function, which will get called when your extension is activated by VS Code. I'm wondering a bit how Joyride scripts should access this object. Trying an API right now with a function in joyride.core that will get this object for you. Like so:
(ns hello
(:require [joyride.core :as joyride]))
(comment
(def context (joyride/get-extension-context))
(.-extensionPath context)
; => "/Users/pez/Projects/joyride"
)joyride.core. An alternative is to do similar to the VS Code Extension API. Then the script author takes responsibility for tucking away the extension context object for later use.I like the simplicity of that your init script will just run, without any activate or main function stuff. It will be nothing special with this script other than that Joyride will run it at startup.
Then there is the deactivation issue as well. VS Code extensions implement a deactivate() script where they can do clean-up. (E.g, Joyride uses this to stop any nREPL server that is running and delete the nrepl-port file). If the init script ”just runs” then what is a good way for this deactivation hook?
• joyride.core could have a function you call for registering a function to be called.
• we could have an exit script similar to the init script. Joyride ”just runs” it as part of its deactivation.
• ...
Anyone has any strong opinions against me going with the ”just run the init script” idea? Other ways to do this? How does this work in Emacs? Etcetera...
@pez Emacs has an ~/.emacs.d/init.el script, I think having the init.cljs scripts in the system + workspace could be nice, but maybe wait until people have a real need for this already?
We could have a de_init.clj too, but again, I would wait for requirements to appear from real usage, rather than guessing what it should be right now
Nah, Joyride will be half-assed without init functionality. And it has already been asked for anyway.
Then I would say scripts/init.cljs would be the most Emacs-ish way
Agreed. And no main or activate or such, right? Does Emacs have something for de-init/exit?
not that I'm aware of
I’d like to be able to have init scripts to do things like create workspace specific vscode settings. I’m not sure if this is something that could be improved by joyride, but you could have a workspace init script that replaces vscode’s settings.json file or modifies it, and that’d be pretty cool
There is VS Code extension API for updating settings so this would definitely be doable from an init script w/o editing the settings.json.
Okay, I’m not surprised there’s an API for it, but even if vscode didn’t have one, I think init scripts would be useful for just this alone
Atom's init script is also very simple - it just runs the code, and if you want to clean up things, you just restart your editor 🤣
I actually would like to have a bunch of "joyride specific" APIs that wrap vscode API in a way that when you deactivate the plug-in, it auto cleanups things
Is their instructions for getting joyride working on windows ? I installed the extension. I created a test.cljs file, I click REPL > Start your REPL with a project and Jack-in, and then nothing happens.
CTRL+SHIFT+P: Joyride Run Clojure Code works just fine. I can run code and see the output in the output window
I reopened the folder in WSL Now when I start a repl I see this:
I will try reinstalling extension in WSL
you need to upgrade Calva as well
NO, installed the exentions in wsl and still i only get option of babashka nd nbb
I'm on v0.0.5
does it not install the latest ?
Calva
aaah sorry im dumb
yay! That worked, thank you!
Where will the user script folder be on WSL ?
Probably in ~/.config/joyride/scripts at least that's what I discussed with @pez, not sure if he implemented it like that
yep: https://github.com/BetterThanTomorrow/joyride#quick-start---start-your-scripts-library
What’s the rationale to having your scripts in .joyride/scripts rather than just .joyride? Is there something else that would go in that top-level directory?
E.g. the .nrepl-port file also goes into .joyride
It's an arbitrary directory nesting, could be argued either way I think
Ahh okay, thanks đź‘Ť