Which Paredit extension are you using in VS Code @U066LQXPZ?

I switched to Strict Paredit recently and it seems like I get fewer hanging parens with that.

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.

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 \.

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!

@U066LQXPZ is this experiment public, private?

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

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.

Whenever you are ready come and chat in #rewrite-clj, I’ve had many interesting, enlightening and fruitful discussions there with @UG1C3AD5Z, @U04V15CAJ and others!

@U066LQXPZ 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

@U3Y18N0UC 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 @U04V15CAJ’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.

@U066LQXPZ 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

@U3Y18N0UC Interesting, thanks, I'll have to dig in more and understand how that's wired up.

@U3Y18N0UC 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)

@U04V15CAJ 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

@U04V15CAJ 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)