I've run into some cases where clover doesn't seem to want to send forms to the REPL. Here's one I can repro reliably. Using @seancorfield's setup, ctrl-;+b (or "Clover: Evaluate current block of code" from the command pallette) does nothing. If I select the code and run "Clover: Evaluate current selection of code" via the command pallette, all I see is a red "Unexpected" in the REPL pane. Nothing shows in the dev tools console. Here's the form:
(-> empty-expr
(handle-keypress \@)
(handle-keypress \])
I believe it's missing a )
here
Ah. You're right. Paredit keeps doing that to me.
Actually, I think I found the culprit here. I'm simulating keypresses by sending characters like \(
to functions. If I have a form like (foo \()
, and I delete the (
after the \
, it takes the trailing paren of the form with it, leaving (foo \
.
(This red message is probably comming from the errors on rewrite-cljs, that I use to parse Clojure code. Probably I'll have to handle it soon-ish 🙂)
As I use parinfer most of the time, these kinds of errors are things I don't usually see, so I believe that's one of the reasons this part of Chlorine/Clover is still very crude...
(FWIW I am still working on rewrite-cljc, just recently dipped my toe back in and am currently up to my waist :simple_smile:)
@dave.dixon nice, I was thinking on something similar some time ago. What I'm trying to make it work right now is a way to be able to edit fragments next to each other. It's similar to the idea of "code bubbles". In the future, I want to be able to trace the evaluation of code then render on the text editor which functions (and forms of these functions, if possible) were called
@mauricio.szabo Yes, I had similar thoughts. First I want to nail down the abstraction of editing the AST directly. Tracing is definitely interesting, I assume you've seen the Flow Storm Debugger. Having that integrated in the editor would be pretty cool. Which leads me to a tangential question (which may have nothing to do with clover...): rewrite_clj(c) overrides the behavior of pr-str
, such that output is no longer valid clojure, looks like <token: foo>
. That's how it appears in the Flow Storm debugger. But if I use a socket REPL with clover, evaluation results print like #rewrite_cljc.node.token.TokenNode{:value foo, :string-value "foo"}
, which is puzzling me since I thought the default REPL behavior was to output via prn
, which behaves like pr-str
. Do you have any insight how this is happening?
I can't imagine that it would be a breaking change to change the <foo>
output since it's only for display, not readable
Agreed. I'd still like to understand where the difference originates.
My guess would be that the original author wanted a more fancy printing output than defrecords have by default
and not print all of the fields
Right. What has me puzzled is how the socket REPL output is different, since I thought it used prn
to send results.
The original author has moved on to other things and is not interested in chats about rewrite-clj. I think @borkdude’s guess is good. I raised an issue to explore for rewrite-cljc https://github.com/lread/rewrite-cljc-playground/issues/64
My question here isn't really about rewrite-clj, it's why clover manages to get a different result than expected, given that the socket REPL is supposedly using prn
.
ah, I see.
@dave.dixon well, I don't really rely on pr-str for most cases. In the case of Clojure, the output comes from the unrepl library that I use in Chlorine
@mauricio.szabo Interesting, thanks, I'll have to dig in more and understand how that's wired up.
@mauricio.szabo so you are effectively using a prepl?
In other implementations, I'm wrapping the output and modifying the way I print (so the code can give more insights on how it's done)
@borkdude not really, I'm using UNREPL over a plain socket repl.
Ah right. I wrote a pREPL for babashka and nextjournal is now using this, along with it they have unREPL like code around it
About flow storm debugger, yes I'm seeing a way to integrate it on Chlorine. Seems line an useful tool to trace data, and the author have a HTML version of the UI (so I believe it'll be easy to translate to Chlorine).
But to be honest, I'm thinking about a way to "loosely integrate" flow debugger - maybe with some additional plug-in that talks to Chlorine / Clover using it's public API. I believe it's useful to have different release cycles for both of these projects.
Also, the author of flow debugger lives really close to me right now, so we can hack things together sometime :D
@borkdude yes, I'm aware they have a prepl implementation (I just didn't know that it came from Babashka), I'm also thinking about using it in place of unrepl
no, babashka offers a prepl that integrates with their blob code (based on unREPL), but their other stuff is based on prepl as well afaik (JVM Clojure)
Ah, OK. I'll probably do something similar in the future (but not based on unrepl - the code is waaay too much complicated to work with)
I'm actually using rewrite-cljc in an experiment to make a better Clojure editor.
Awesome! Ah, I see you recently joined our little #rewrite-clj channel!
Yes, I'll probably be chiming in there soon...🔔
Sweet!
Which Paredit extension are you using in VS Code @dave.dixon?
@dave.dixon is this experiment public, private?
I switched to Strict Paredit recently and it seems like I get fewer hanging parens with that.
Public, but just barely started proof of concept (like started today). I'm currently convincing myself that it's possible/desirable to do zipper-based editing of Clojure code based on a stream of keystrokes. All just REPL experiments now. https://github.com/sparkofreason/zipped
Strict Paredit. I need to find a reproducible case, but it seems like sometimes when a do a paredit-based copy/cut and then paste, I somehow manage to lose a trailing paren. I need to pay more attention at try to catch it earlier.
The idea is to make the AST (via rewrite-cljc, at this point) the core representation, rather than text. Seems like there's a list of possible benefits that arise from there, still needs to be proven though.