[HN Gopher] Show HN: Joyride: script VSCode like Emacs but using...
___________________________________________________________________
Show HN: Joyride: script VSCode like Emacs but using Clojure
Together with PEZ (Peter Stromberg) 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...
Author : Borkdude
Score : 196 points
Date : 2022-04-29 09:06 UTC (13 hours ago)
| EnigmaCurry wrote:
| 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.
| joenathanone wrote:
| Didn't know this was a thing, my whole life is a lie!
| cospaia wrote:
| 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.
| christophilus wrote:
| Do you ever sleep? Seriously; your productivity is insane.
| cospaia wrote:
| 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.
| christophilus wrote:
| Well, that goes without saying. We all know that borkdude
| is a robot.
| leifericf wrote:
| Both you and borkdude are productivity beasts (of the
| kindest variety) in my mind :)
| ungamedplayer wrote:
| Parens are love. Parens are life.
| kitd wrote:
| _Parens f*** you up_
|
| - Philip Larkin
| gorjusborg wrote:
| Say hello to my little parens!
|
| - Tony Montana
| mijoharas wrote:
| Parens are laugh.
| seanw444 wrote:
| Live, laugh, love syntax errors.
| leifericf wrote:
| Hugs for your code!
| yogthos wrote:
| 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.
| cospaia wrote:
| Thanks! Please consider filing your suggestion as an idea on
| the Joyride discussions section:
| https://github.com/BetterThanTomorrow/joyride/discussions
| tgv wrote:
| 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?
| Borkdude wrote:
| This is possible, but it's a bit more code. Watch the
| introductory video that PEZ made where he does something
| similar.
| Borkdude wrote:
| 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.
| ..
| tgv wrote:
| Nice!
| macmac wrote:
| Sure it is. You could use a cljs closure over an atom.
| oefrha wrote:
| You mean whether VSCode extensions (1) can insert into the
| current line; and (2) have state? The answer should be rather
| obvious, yes.
| tom_ wrote:
| 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.
| oefrha wrote:
| 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.
| macmac wrote:
| This is not correct. Use of the CLJS REPL to insert
| strings is even demonstrated in the video.
| oefrha wrote:
| 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.
| Borkdude wrote:
| That would be possible with joyride as well. Ask for user
| input, then evaluate it.
| macmac wrote:
| Or do it directly from the REPL.
| mschaef wrote:
| > 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.
| cospaia wrote:
| 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.
| swah wrote:
| 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).
| cospaia wrote:
| =)
|
| Writing that made me challenge it. What if it is
| possible? https://github.com/BetterThanTomorrow/joyride/d
| iscussions/14
| rockyj wrote:
| 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.
| Borkdude wrote:
| 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
| christophilus wrote:
| I thought Lumo was this, tough that project might be dead.
| ShadowCljs is pretty close.
| Borkdude wrote:
| Lumo is one instance of what you can do with self-hosted CLJS
| and yes, the project is unfortunately dead.
| markus_zhang wrote:
| Oh this could be fun. Anything other than JavaScript/Typescript
| is good.
| beepbooptheory wrote:
| 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.
| cospaia wrote:
| Which fine steak would that be?
| beepbooptheory wrote:
| The steak is the lisp interpreter as IDE scripting runtime.
| cospaia wrote:
| Ah, so it's the editor war we are fighting here? =)
| snorremd wrote:
| 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.
| maleghast wrote:
| 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!
| vincent-manis wrote:
| I am certain that this is excellent work. I, however, will
| continue using Emacs.
| kralhackimer001 wrote:
| andriosr wrote:
| 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...
___________________________________________________________________
(page generated 2022-04-29 23:01 UTC)