paredit vs smartparens vs other? does the CIDER team have any recommendation?
I'm not from CIDER's team but I want to throw in some of the "others". I'm using lispy for a while now and it works flawlessly so far https://github.com/abo-abo/lispy
I'm using paredit, but in the past I've rolled out smartparens for the team that wasn't used to paredit editing. Smartparens is by default more lax about paren balancing, so it's easier to get started with, I suppose.
But I'd say either works well enough to not feel the need to look for alternatives.
I've used the same Paredit version for more than 10 years - hard to break, nice to build stuff on top on But I also use smartparens when on Ruby or others. And would be open to Lispy for this use case https://clojurians.slack.com/archives/C099W16KZ/p1725537935367599?thread_ts=1723474454.408799&cid=C099W16KZ
This article makes a great case for not relying on all-encompassing packages like Lispy and instead incrementally building your own system from composable parts: https://karthinks.com/software/a-consistent-structural-editing-interface Combobulate seems like a really interesting paradigm to check out if you're starting fresh - probably not worth the switching cost for those of us already acquainted with paredit/lispy etc.
As an evil-mode user I use a heavily-modded version of lispyville but wouldn't recommend it to others... it's somewhat buggy and unmaintained, and lispy (which it uses as backend) feels way too opinionated with how it handles Clojure code in particular.
fwiw (not much) I use, and verily enjoy, smartparens
After a year or so, I only tried paredit, and it still costs me to enable it, but once I do and start slurping and barfing, oh man, it always reminds me of "real programmers use butterflies". amazing feeling.
yeah, I think "doing structural editing instead of not doing structural editing" is a much bigger difference than "paredit vs smartparens". π
I've been using structural editing for years and still get a tiny adrenaline rush every time I get to use the convolute command β¨
paredit has conlficting keybindings with xref and I dislike the way it assigns keybindings. I go back and forth between it and smartparens
Lispy +1
For the record - Iβm also a paredit user. π
I also like smartparens, but IMO paredit works a little bit better for Lisps.
Hi, Here's a curious feature I bumped into. I'm running CIDER (1.15.1) and Shadow-CLJS while developing a type with a custom print. I've reduced it into this example. I'm implementing IPrintWithWriter
(deftype TestType []
IPrintWithWriter
(-pr-writer [this writer _]
(-write writer "this should print")))
But the output is cut short. Further weird behavior with e.g. # and [].
> (TestType.)
this
I believe the problem is part of CIDER. It does not reproduce in a plain CLJS REPL or Shadow's non-CIDER REPLs. Can someone explain to me what is happening and how I would be able to inspect the true values inside CIDER (print could include complex structure)?Might be something related to the changes weβve done in nREPL 1.3. @alexyakushev might be able to help you, but Iβd suggest filing a some issue about this, so it wonβt go unnoticed.
At least this one is easy to reproduce. I'll post an issue tomorrow.
Can you please change cider-injected-nrepl-version to 1.2.0 and try again? That would confirm if the behavior has to do with the new nREPL version.
OK, I customized the variable, re-jacked-in (with nREPL 1.2.0 showing) but it still doesn't work.
You can just copy & paste those two bits of code to any REPL to see the bug in action. If it doesn't repeat for you, then I'll investigate more. But like I said, in non CIDER REPLs there doesn't seem to be a problem.
I created this issue https://github.com/clojure-emacs/cider/issues/3741
I'm still not sure if it's a user error or a bug somewhere. I didn't find a lot by searching so maybe it's quite a niche feature. I bumped into custom printing since I'm implementing a kind of reactive atom of my own. This sort of thing is also used in e.g. Reagent.
Thank you for trying out and creating the report!