cider

Felix Dorner 2024-09-09T11:23:20.445479Z

paredit vs smartparens vs other? does the CIDER team have any recommendation?

Kirill Chernyshov 2024-09-09T11:25:53.478219Z

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

oyakushev 2024-09-09T11:28:53.316749Z

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.

oyakushev 2024-09-09T11:30:03.304909Z

But I'd say either works well enough to not feel the need to look for alternatives.

vemv 2024-09-09T11:31:43.499849Z

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

yuhan 2024-09-09T15:36:46.780559Z

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.

yuhan 2024-09-09T15:44:16.589479Z

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.

Harold 2024-09-09T16:26:13.766209Z

fwiw (not much) I use, and verily enjoy, smartparens

Felix Dorner 2024-09-09T16:29:47.968039Z

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.

πŸͺ„ 1
Harold 2024-09-09T16:40:17.934469Z

yeah, I think "doing structural editing instead of not doing structural editing" is a much bigger difference than "paredit vs smartparens". πŸ™‚

yuhan 2024-09-09T16:43:28.768049Z

I've been using structural editing for years and still get a tiny adrenaline rush every time I get to use the convolute command ✨

πŸ’― 3
Derek 2024-09-10T17:02:30.454679Z

paredit has conlficting keybindings with xref and I dislike the way it assigns keybindings. I go back and forth between it and smartparens

2024-09-15T22:54:44.111379Z

Lispy +1

bozhidar 2024-09-11T19:55:30.188949Z

For the record - I’m also a paredit user. πŸ™‚

bozhidar 2024-09-11T19:55:54.685099Z

I also like smartparens, but IMO paredit works a little bit better for Lisps.

Macroz 2024-09-09T06:38:35.225369Z

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)?

bozhidar 2024-09-11T19:58:27.541109Z

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.

βœ… 1
Macroz 2024-09-11T20:40:05.502009Z

At least this one is easy to reproduce. I'll post an issue tomorrow.

oyakushev 2024-09-11T20:41:06.788379Z

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.

Macroz 2024-09-12T05:14:15.781309Z

OK, I customized the variable, re-jacked-in (with nREPL 1.2.0 showing) but it still doesn't work.

Macroz 2024-09-12T05:15:32.750169Z

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.

Macroz 2024-09-12T05:31:51.890639Z

I created this issue https://github.com/clojure-emacs/cider/issues/3741

Macroz 2024-09-12T05:37:34.965759Z

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.

oyakushev 2024-09-12T06:17:07.269259Z

Thank you for trying out and creating the report!

πŸ™ 1