Clojurians Log v2

@borkdude has joined the channel

set the channel description: Come on, join the joyride! https://github.com/BetterThanTomorrow/joyride

@pez has joined the channel

set the channel topic: Come on, join the joyride! https://github.com/BetterThanTomorrow/joyride

🎉

@zarkone you seemed excited about this idea. 😃

@zarkone has joined the channel

hi @borkdude @pez! thanks for inviting! yes, very excited! Would be really glad to participate and see if this project could make me switch to vs code from emacs, which I was thinking impossible before I knew about it. Would be happy to help with anything: pairing, emacs expertise, etc 🎉

I will certainly not switch from emacs to vscode, but I'm still excited about this ;)

I was thinking that would be a great experiment at least, -- at least temporary

I consider vscode as my secondary editor at the very least though :)

I think the target audience should be folks who already use vscode + clojure (calva users?) that want to use clojure to extend their editor experience

one thing could still hold me in emacs, even if vscode would get joyride onboarded -- GUI manipulation limitations, buffer mgmt

Yes. VS Code is surprisingly stupid about a lot of those things. It is improving. But often with some very special solution. ”Now you can move Webviews into the Panel area”. Why? I want to move anything anywhere. There is prior art. Tons of ir.

I'm just exploring the VSCode API. I found this. Show the contents of the clipboard.

(require '["vscode" :as vscode]
         '[promesa.core :as p])

(p/-> vscode/env.clipboard
      (.readText)
      (vscode/window.showInformationMessage))

@zarkone if you want to take it for a spin, here's a vsix: https://www.dropbox.com/s/86h9ypuba42ydz2/joyride-0.0.1.vsix?dl=0

I just pushed a command for loading the current file.

what is "the current file"?

This is the current file

hell yeah! perhaps we should use consistent words for "load" and "run" in the commands?

Run goes nicely with Joyride 😃 But when naming this one I thought it felt more lika loading it, getting prepared for working with it... In babashka files I often have a conditional thing at the bottom which checks if the script is being run in the REPL or not, and does different things, often not doing much if it is in the REPL. Maybe we can do something similar here. Provide some variable you can check if the file was loded or is supposed to run. Then we would have two commands, one that runs, and one that loads. They will do the same if you are not checking the variable, but anyway. And loading could be named Evaluate.

@zarkone if you haven't already, please see if the build instructions are OK enough.

I added a command for evaluating the selected text. Until we have an nREPL server that can compensate some, I'm thinking. However, I need to know the namespace of the file in order to be able to evaluate pieces of it with any good results. Right now I work around it like in the video. But of course better if we can use the ns form. Pondering if I should expose Calva Paredit from Calva's API then we can use that and users will have a consistent experience with how Calva sees things. But also, I don't know if I'm ready to start considering other users of the Paredit API... Maybe just expose some well selected functions? Advice welcome. Also advice about alternative approaches. Just grabbing the namespace symbol can be somewhat reliably done with a regex. Calva did it that way for a pretty long time. I'm also looking at the loadFile example on the SCI page, but I don't understand it well enough to figure out if I could go that way.

I think it's better to implement a proper nREPL instead of a sub-optimal near-REPL

although perhaps it already works if you first eval the ns form?

Yeah, it actually does.

it's not so hard to parse the ns form, but maybe you can make an issue and let me do that

since that's more in the SCI side of things

we could probably re-use some stuff from nbb's nrepl thing eventually when we want to have proper nREPL

Yeah, that or it is on the Calva side of things 😃

I think it's better to not couple this to any specific plugin

> when we want to have proper nREPL Like now? 😃

E.g. with nbb I don't require people to install bb as well. It's good to keep stuff separate

Yeah, but we can enable things if they are available and otherwise not.

But, I hear you. Will chill with the Calva track.

> Like now? I think it's better to focus on the initial features and make them ready, then incrementally do the more difficult stuff. nREPL is not hard, but it will take a few hours

An API from Calva will need to be exposed at some point to allow users to take Calva on a Joyride.

yes, but this is on the level of letting users call that from their scripts, not a hard requirement to use joyride

My thinking above was not about a hard requirement either. More like ”features that enable if you have Calva installed”.

right 👍

Featurewise we are not far from where nREPL is the next step, I think.

if you have calva installed, you can probably launch a joyride nrepl, connect to it and then do stuff like with any clojure script? not anything specific to joyride I think?

Yes and no. When Joyride has an nREPL server you will be able to connect to it and have the same level of REPL tooling support as nbb has (so not full cider-nrepl, but enough to be productive). However, I think I will also make something special or something general with Calva to allow it to be connected to both Joyride and your project.

So perhaps joyride should expose a VSCode API to launch an nREPL server which returns the port and possibly more stuff and calva could call that API?

As it is now it takes: 1. connect to Joyride, 2. do things 3. connect back to your project

Easier if we spit out the port in the .joyride folder. That kind of ”API” Calva is already prepared for.

makes sense. but let's say, if the user selects in calva "connect to repl in project, aka jack in" > "joyride", then it needs to call something in joyride right?

to start the nrepl

since it's not a command line thing it can call like bb or nbb

I'm thinking that when Joyride activates it will start an nrepl server and users will not start it, but rather connect.

but joyride always activates and I don't think it's clean to always start an nrepl since that uses an open port, etc.

perhaps just a joyride.startNRepl and joyride.stopNRepl could work

commands

I could go with unclean. But we can have a command for it. And we don't need to always activate Joyride either.

Yeah, you had the same idea.

but if instead of a command we expose a VSCode API, then Calva could do that work when the user selects "joyride"

that seems more in line with how it's done for other tools

Could do what work?

tell joyride to start the nrepl

Calva would use the commands, was my thinking.

ah yes, that works

And the Joyride user will want those commands too if we think it's dirty to just always start it. (I don't think that's very dirty).

I do. if you have n windows open , there will be n ports open, not a fan of that

we could make that a configuration option of course, if you insist :)

Then commands. Otherwise people will have to use Calva to start the repl and then connect Emacs if that's where they fancy to work from.

I think joyride's audience is VSCode users ;)

> we could make that a configuration option of course, if you insist Not a fan configurable options. 😃 But this one makes sense. Then at least it is not dirty.

> Not a fan configurable options. Then why do we have an option for user and workspace script directories ;)

That's because I like the Ux it creates.

I mean, you would have the same UX if these would be always .joyride/scripts

without the option to change that

(I'm totally fine with the option, just challenging your "don't like configurable options")

That's what we are planning, right? At least I. 😃

That's not what you wrote here though: https://github.com/BetterThanTomorrow/joyride/blob/master/doc/configuration.md • joyride.scriptsPath.user: An absolute path • joyride.scriptsPath.workspace: A workspace relative path. Defaults to .joyride/scripts.

(I added the default sentence after it since it wasn't clear what the default was)

It is more like that my default answer for if something should be configurable is No. But if I need it for something, then I add it.

I agree, but here we didn't even need it yet

Yes, defaults makes sense. The current setting we have for this has a default too.

(and it's also currently not implemented)

Ah, I missed a key word there, you said ”without”, I read ”with”.

I agree that we should not add options for the sake of adding options. But we seem to have documented options that 1) aren't implemented 2) haven't been requested by anyone yet. Those were my points

Here's the reason I want this configureable the way I have suggested:

brb

VS Code has User and Workspace settings. Workspace settings take precedence. So if I would like a different set of Joyride workspace scripts for a particular workspace than my colleagues have, I can configure that in my User setting. It's a kind of flexibility I like to have. Or maybe I have my user scripts on a memory stick and use several computers. Idk. Just makes sense to me.

And monorepos.

However, things have also changed since I frist scetched this. So maybe we can chill with the settings and see what kind of needs arise.

ok. What I also wondered: you will bind $workspace/.joyride/scripts/foo.cljs to a hotkey. But that hotkey only makes sense within that specific workspace... but VSCode doesn't have the concept of workspace-local hotkeys right?

Good catch! ... Maybe it has. Let me check.

https://stackoverflow.com/questions/48945319/a-keybindings-json-per-workspace-in-visual-studio-code

but this is why you have the menu with the workspace scripts

ok, so you can have local .vscode/settings.json and you can use these settings in a when in the global hotkeys

Checked, there is no such when context. But we can add it.

{
    "key": "cmd+1",
    "command": "joyride.runWorkspaceScript",
    "args": "my_ws_script-foo.cljs",
    "when": "joyride:workspacePath ~= /project-foo/"
  },
  {
    "key": "cmd+1",
    "command": "joyride.runWorkspaceScript",
    "args": "my_ws_script-bar.cljs",
    "when": "joyride:workspacePath ~= /project-bar/"
  },

Well, something like that. 😃

is ~= a thing? what does that mean, a regex?

Yeah, I'm not sure if that's the syntax. It is in awk 😃

so you're just making stuff up now? ;)

😃 I know you can match on regexes. So just the syntax could be a bit off.

fair enough :)

Calva is using quite a few when context things.

But that SO answer would work too. Maybe better to document our way around it.

wasn't what you were doing similar to the SO answer?

I see you are using a colon in joyride:workspacePath , does that have a special meaning?

Similar. But my idea wouldn't need a workspace level setting. Which I often try to avoid.

Funny about the colon. I was asked the other day. No, I don't think it has a meaning. I think I picked it up from some example and now it's what I use in Calva.

I gotta wrap up. To conclude, I think we should have a fully working minimal thing and ship it. Then wait a bit for user feedback. Then the next iteration (nREPL support).

I might want to have a few things in place before shipping. But putting it on the marketplace and just tell our friends around here to start testing I am cool with, without too much structure.

ok, then I think having some more structure about what are the items that should go in before shipping, e.g. an issue with some items in it, would be nice

Yes, I'll file an issue or two.

sounds good. g'night!

Part of my plan here is that Joyride could be a vehicle for growing Clojure. But Clojure w/o a REPL ... So for me I think I want a REPL before shipping. 😃

Good night!

My thinking is that we should test if this idea is something users want, before putting too much energy in it. The energy comes from usage (for me personally). If there isn't any usage, I see it as a waste of time to put many hours in nREPL support.

It's similar with #obb - a REPL if of course planned, but I don't think there are currently enough users and the people who have requested a REPL is 0 or 1 maybe

Just evaluating your whole script is good enough for now to see if this peeks more interest

In that sense your evaluate selection is a good proxy

I'll take a look at the namespace parsing tomorrow hopefully

Since it is temporary we can also just regex it. 😃

neh, it's not that hard to do it with SCI

I think we should even eval the ns form before the selection, I think CIDER does that too

Maybe. Calva only evals (in-ns ...) . Never evals stuff you haven't told it to evaluate.

Maybe. Also, the ns stuff requires some more changes in how we eval, eval-string* is no longer sufficient. I'm working on an in-browser nREPL server at the moment (for clerk and scittle) where I'm doing something similar

Well, maybe with some luck I can copy the nbb nREPL stuff to joyride and it'll be not too much work... :-S but optimally I want to factor out the common parts and do it cleanly...

anyway, now I'm really away :)

Do the factoring if Joyride takes off? 🧌