Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Joyride: script VSCode like Emacs but using Clojure
211 points by Borkdude on April 29, 2022 | hide | past | favorite | 44 comments
Together with PEZ (Peter Strömberg) I made a VSCode extension that allows you to script VSCode using Clojure (interpreted CLJS).

The repo: https://github.com/BetterThanTomorrow/joyride

Introductory video:

https://www.youtube.com/watch?v=V1oTf-1EchU

See examples directory:

https://github.com/BetterThanTomorrow/joyride/tree/master/ex...

See animated gifs and news on Twitter:

https://twitter.com/hashtag/vsjoyride?src=hashtag_click&f=li...




Wow, really excited by this! The Calva extension gave us a really nice editing and REPL experience for Clojure code. Now we get to interactively configure VSCode with Clojure code which is pretty dope. I used Spacemacs at my old workplace for some time, but never got into making custom configuration. I never got into the emacs lisp library or the syntax peculiarities. Though I suspect the minor syntax differences would be the least problematic to learn. Now I use VSCode Calva and will definitely check out Joyride as it uses SCI and allows me to use the Clojure library that I already know and love.

People who like this should consider sponsoring both Borkdude and PEZ on GitHub. They do amazing work for the Clojure ecosystem.


As the co-creator here I'd like to add that Joyride is taking the very first baby steps here. We hope a lot of people want to try it and provide feedback to inform our next steps.

NB: The video has a target audience of people who know Clojure and its strengths. Especially how the REPL is used. I hope HN will see beyond the parens. =) It should make some sense anyway. Especially if you have some Emacs scripting experience, because that is where most of the inspiration to Joyride comes from.


Do you ever sleep? Seriously; your productivity is insane.


Tbh, the last nights have been less about sleep and more about hacking on Joyride. =)

But usually I do get sleep. The question we should ask is if borkdude sleeps? He's doing about 100X as much as I do. Maybe there are hundreds of borkdudes.


Well, that goes without saying. We all know that borkdude is a robot.


Both you and borkdude are productivity beasts (of the kindest variety) in my mind :)


Parens are love. Parens are life.


Parens are laugh.


Live, laugh, love syntax errors.


Hugs for your code!


Parens f*** you up

- Philip Larkin


Say hello to my little parens!

- Tony Montana


Fantastic work on the extension. In terms of ideas for next steps, my suggestion would be to consider automating the process of creating and invoking cljs files. One big use I can see for this is creating ad hoc scripts to do stuff in the editor. If you could pop up an editor via some shortcut that would allow you to create a script and bind it to a shortcut, that would make using Joyride really seamless.


Thanks! Please consider filing your suggestion as an idea on the Joyride discussions section: https://github.com/BetterThanTomorrow/joyride/discussions


That looks promising, but I have a feeling that vscode doesn't offer as much options to hook into the editor as emacs does. E.g., one of the first emacs scripts I wrote added the next number to the current line. It contains something like

    (insert (number-to-string (setq counter (+ 1 counter))))
Is that kind of thing possible too?


> That looks promising, but I have a feeling that vscode doesn't offer as much options to hook into the editor as emacs does.

Agreed on both counts.

But I don't think it's possible to get to Emacs' level of extensibility unless you adopt its philosophies - both legal and technical - from the outset.

The reason I say this is that Emacs isn't just extensible in Emacs Lisp, it's very extensively written in Emacs Lisp. More than that, the code behind all of the functions is a keystroke or three away. If I want to know what 'C-x C-s' does, it's possible to say 'C-h k C-x C-s' and see this:

> C-x C-s runs the command save-buffer (found in global-map), which is an interactive compiled Lisp function in ‘files.el’.

There's more documentation besides, and pressing enter on 'files.el' then takes you to the source code for the save file function. This works for native C code too, provided you have the source installed.

This is very much like what you see in a Smalltalk image or a Lisp machine - the system is all 'of a kind', self-documenting, and fundamentally open by nature.

Web Browser JS environments have some of the interactivity here, but they miss out on the self-documenting part, the use of the extension language as an implementation language, and all the cross linking into the source. I'm not faulting them - these are expensive and time-consuming choices to take - and they are often at odds with the goals of writing a useful browser.

In that perspective, the work here is admirable in that it adds Lisp style scripting to VSCode, but it's destined to never get close to the sort of interactive extensibility and exploration you get in Emacs itself. I'm sure it's easy to run into the wall between the extension language and the implementation language itself.

Before this is taken as too critical, note that I don't mean it that way. This is just an observation about two different design choices based on two different sets of constraints that have led to two different outcomes. Note that both of these outcomes are good and useful points in the design space.


It is definitely true that Joyride can't make VS Code as fully extensible as Emacs is. VS Code is not designed this way. And also some extensibility from an extension need to come from an extension manifest when an extension loads, so Joyride can't declare new commands for instance. I'm guessing that is the simplest thing in Emacs.

Having, draw a rendom number out of a hat, 50% of Emacs extensibility at your REPL is fantastic, and worth pursuing. Joyride can do everything a VS Code extension can do, except the things i mentioned above, and anyone who has used some VS Code extensions knows that that is a lot.

However, the self documenting part described above is not out of reach. Most of the code building up the VS Code API is open source. Same goes for many of the extensions. Looking up and navigating to any of that code is possible. Perhaps a lot of work would need to be put in, but it is possible.


And when/if VS Code decides to allow new commands without the manifest (maybe with a confirmation popup), Joyride is super well positioned as a way to customize your VS Code (well, from users that don't hate parens).


=)

Writing that made me challenge it. What if it is possible? https://github.com/BetterThanTomorrow/joyride/discussions/14


This is possible, but it's a bit more code. Watch the introductory video that PEZ made where he does something similar.


I made a rough example here which insert the increment number at cursor by looking at the last number in the line:

https://gist.github.com/borkdude/08ec3ae2af5963a4a03cd8e0873...


Nice!


Sure it is. You could use a cljs closure over an atom.


You mean whether VSCode extensions (1) can insert into the current line; and (2) have state? The answer should be rather obvious, yes.


I assumed the point is whether you can do this from the repl? This is something Emacs is good at, but VSCode doesn't seem to be; in Emacs, you can do something like M-: (insert "FRED") RET and you'll see FRED appear in the current buffer. For good or (more rarely) for ill, the repl runs in the same context as the editing environment. You can use this to interactively develop extensions or just drive the editor from code as a one-off.


GP said “scripts”. But no, VSCode certainly doesn’t have that level of interactivity. On the other hand, the single-threadedness of Emacs is very annoying though.

Edit: My usage of Emacs has been reduced to mostly just magit and dired since ~2017, so I didn’t realize Emacs 26 added threads. Is it actually widely adopted? Things I do use these days, like package.el, are clearly still blocking.


This is not correct. Use of the CLJS REPL to insert strings is even demonstrated in the video.


Sorry, I wasn’t clear about it but I was talking about extension capabilities offered by stock VSCode. There’s nothing stopping third party extensions like Joyride from exposing the extension API in an REPL.


That would be possible with joyride as well. Ask for user input, then evaluate it.


Or do it directly from the REPL.


Super cool! I've been planning integrating https://runops.io/ to VSCode for a while and most of the delay is related to having to write Javascript. I like your wrapping of the VSCode js API. I'll use as inspiration for creating the Runops extension using cljs in the near future. Super exciting that I can do something like this for VS code now: https://andrios.co/articles/spacemacs-cheatsheet/#elisp-func...


Definitely understand the need and looks good, but can't help but feel this is like taking a fine steak and eating it at McDonalds.


Which fine steak would that be?


The steak is the lisp interpreter as IDE scripting runtime.


Ah, so it's the editor war we are fighting here? =)


This is so great - the expanding universe of Clojure / ClojureScript tooling and so forth is great to see and great fun to use, whether in anger or just out of curiosity - thanks for this, I know what I will be exploring over the weekend!


I am certain that this is excellent work. I, however, will continue using Emacs.


long time emacs user, I've tried vscode a few times. I will not go back to try it again until it has emacs-style undo tree https://github.com/Microsoft/vscode/issues/20889. Emacs bindings are no good if they do completely different things.


Didn't know this was a thing, my whole life is a lie!


Nice! I really wish we could have a CLJS -> JS compiler in pure JS (something like TypeScript) and no need for JVM or JVM libs.


This exists and is called self-hosted ClojureScript. To be clear, you don't need that nor do you need a JVM to write joyscript scripts, as the scripts are interpreted by SCI, a Clojure interpreter:

https://github.com/babashka/sci


I thought Lumo was this, tough that project might be dead. ShadowCljs is pretty close.


Lumo is one instance of what you can do with self-hosted CLJS and yes, the project is unfortunately dead.


Oh this could be fun. Anything other than JavaScript/Typescript is good.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: