This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (3)
- # babashka (42)
- # beginners (84)
- # calva (3)
- # cider (13)
- # clj-kondo (9)
- # cljs-dev (6)
- # cljsrn (32)
- # clojure (47)
- # clojure-argentina (4)
- # clojure-france (2)
- # clojure-spec (17)
- # clojure-uk (15)
- # clojuredesign-podcast (4)
- # clojurescript (41)
- # conjure (53)
- # cursive (16)
- # data-science (5)
- # duct (1)
- # emacs (11)
- # events (1)
- # exercism (3)
- # fulcro (48)
- # graalvm (20)
- # graphql (1)
- # joker (3)
- # kaocha (2)
- # malli (2)
- # meander (6)
- # pathom (3)
- # planck (18)
- # rdf (3)
- # re-frame (14)
- # ring-swagger (1)
- # shadow-cljs (15)
- # specter (1)
Hello @olical, I have enjoyed your articles on the clojure prepl. I want to essentially create a conjure for kakoune. I have gotten the base prepl examples working and started to use Propel as a base for my project. Sorry for the newbie question, but how can I add something like colorized output?
Hey! Interesting idea! I haven't actually had a look at Kakoune and it's extensibility, how is it?
Also worth noting that I'm currently rewriting everything to lean on nREPL since I'll be able to provide a bunch of smarter tools in a fraction of the time. Also prepl CLJS support is pretty shaky at the best of times despite all the effort I put into fixing it.
It uses the unix philosophy, so stdin and stdout. I plan to heavily use babashka as a sort of middleware when I don't want to write bash
Highlighted output for Conjure is for free since I write all output into a Clojure buffer that the user can edit.
I think prepl is still solid if you're building something simpler and you don't care about flawless ClojureScript support as much.
Since I'm all about UX, ease of use, smoothness I'm swapping foundation for something that will allow me to be a little more ambitious while improving ClojureScript support massively.
The way kakoune does editing I feel is superior than vim. You always get feedback on what selection your going to apply an action to as opposed to vim where you do an action and hope you got the right selection (unless you always use visual mode)
are you planning to use the orchard/cider as a base for your project or start with the vanilla nRepl
I'm targeting vanilla nREPL for the base features but it'll sniff for available nREPL operations such as completion, info (for go to def across clj and cljs) etc.
So testing, eval, source lookup, doc lookup are all without CIDER, but I lean on CIDER where things get tricky.
gotcha. I will be keep in an eye on it and attempt to follow in your footsteps. Good luck!
Feel free to ask away with any questions you may have, the prepl side and lispy tooling in general has been my side project for ~3 years now
One question I have that I can't find any info on...actually two. 1. Can you use tools like parinfer-rust as a way to do paren matching and indention? Can you use tools like clojure-tree sitter to do static analysis for syntax highlighting, linting, etc? These are both binaries, so probably not but just wanted to see if I could use the same method i am using in the editor, in the repl to get a similar UX.
Hmm, I'd say parinfer-rust should be a completely separate tool to repl tooling that a user can opt into since it's SUPER opinionated about how you edit. Lots of people won't like it (myself included actually!)
Not sure how you mean to use it though, in editor tooling? Because people definitely do that
And as for tree-sitter, it's getting integration in Neovim at some point soon and I'll be using it to extract forms for evaluation ASAP
I think that is where I was going with it. Can you use a tool like parinfer-rust to look at a repl?
It's much better than hunting for matching parenthesis in the buffer's raw text. Being able to traverse the AST as data will be amazing.
"Can you use a tool like parinfer-rust to look at a repl?" :thinking_face: not sure what you mean by this, sorry. Like, use it inside a REPL (like at the terminal)?
I don't want to do indention in nrepl if a user could use a parinfer tool....-> yes that is what I mean
Changing a few things to avoid CIDER where I can but then use it if required. So doc lookup works without it, but if you try to use it on Java classes and stuff it'll ask CIDER since
(doc ...) doesn't work with those.
Doing as much as I can without it but using the middleware where it's very clearly better than my simple approach.
Pushed the doc changes to develop. Tries to use plain ol'
(doc ...) but will fall through to CIDER's
info op if it's there for things like Java classes.
https://asciinema.org/a/F4EH6nSAe4jbKLfBSY1BDqcqE clip of regular doc falling through to CIDER.
Going to focus on shadow cljs integration for the time being since figwheel requires piggieback and there's a divide between figwheel-main and lein-figwheel. I'll let it sit in my head for a while longer before I add any specific integrations.
Basically going to add a command that runs the code you need to hop your nREPL connection onto a shadow-cljs connection.
So shadow will be the first first class citizen of Conjure's CLJS support, with more to come eventually.
Ah, screw it, I can add a generic piggieback command that takes some raw clojure code so you can hook it into anything you want.
:ConjureShadowSelect app now switches the shadow-cljs nREPL connection over to CLJS mode and all further evals take place in the browser 👌
now works too!
:ConjureEval (require 'cljs.repl.node) :ConjurePiggieback (cljs.repl.node/repl-env)
Connecting to a shadow-cljs server, evaluating some code and then restarting Neovim right back into the session you were working with https://asciinema.org/a/hMzFfvPhB6gNpS2r6nfmEfYLt So you can restart Neovim and still be connected to your browser 😄
Hey I saw that when the vertical split HUD is open the floating window HUD stils shows up, is that a expected behavior?
If your cursor is at the bottom of the log you shouldn't be seeing it. If the cursor is anywhere else in the log it'll pop up because you might not be able to see the bottom.
Ok, I mean the HUD and the buffer shows the same information right? Maybe when you have the buffer open you don't need the floating HUD? Just wondering 🙂 Anyways great work with shadow cljs, this will be huge, I can see a buch of people comming from fireplace to conjure
Oh no, I agree that displaying it twice would be bad. If you have the log open with the cursor at the bottom following along with new output you shouldn't see the HUD.
I could try to make it so if the last line of the log buffer isn't visible the HUD will appear, but I'm not sure if I can work that out.
I know the HUD can overlap with what's visible in the log buffer, I can improve it and make it smarter, but I want the HUD to appear if you can't see the bottom of the log buffer. I don't want things being added without you knowing basically.