Clojurians Log v2

I felt it worthy of a design doc https://github.com/clj-commons/rewrite-clj/blob/lread/paredit-decorated-nodes/doc/design/paredit-and-restricted-nodes.adoc

oh, looks quite promissing! I bet @andreribeirocamargo and @arthurfucher would be interested, andre may have suggestion to contribute too

It's a bit rambly and wip at this point, but maybe we can go over specific cases.

That would be great. Happy to hear feedback from other users of paredit too.

Error handling is of interest. To no-op or throw. (I'm thinking of no-op, but looking for feedback).

And am happy to no-op (or throw, tbd) for more complex cases if that makes more sense.

having a error handling sounds good, although not very useful for clojure-lsp especifically as we still need to code each on of the features manually to accept those ops on lsp side.

We could start with a simple-ish case. What should splice on '|[1 2 3] do? Since paredit is a higher level API, we should think from the perspective of paredit rather than rewrite-clj nodes. I see options: 1. no-op (or throw, throw is current behaviour) '|[1 2 3] 2. raise but preserve quote on first form '|1 2 3 3. raise and lose quote |1 2 3

I'm trying to think from the perspective of a user in an editor.

at least on emacs (what I think is usually the most close to what paredit should look like): • '|[1 2 3] => does nothing • '[|1 2 3] => '1 2 3

Hmmm... it is tricky. We do not want to break compatibility with the existing splice (which is the same as rewrite-clj.zip/splice). The current splice only splices when at the start of a seq, not when in a seq. We could always create a new splice in paredit, I suppose.

why we do not want to break compatibility with rewrite splice? for me itś more important to be consistent with paredit than rewrite-clj custom splice feature

you said yourself we should think as the user/paredit and not rewrite-clj 😅

Oh because rewrite-clj.zip/splice exists in the wild, and so does rewrite-clj.paredit/splice (which just calls rewrite-clj.zip/splice). So I don't want to break existing users of either.

If we want a different basic behaviour, we'll need options on the existing rewrite-clj.paredit/splice or a new fn rewrite-clj/paredit . Which are both ok with me if that makes sense (I did this to address some design problems in slurp).

A perhaps more straightforward example is a slurp on '[1 '|2 3] 4, to me it is pretty clear that this should result in '[1 '|2 3 4] , and I've fixed this in my branch already.

> a new fn rewrite-clj/paredit that makes a lot of sense to me, TBH I even think this could be a separated paredit.clj lib using rewrite-clj or even not, but being as closest as possible of a ideal user paredit feature

Yeah, I think that makes sense... but... I'm focused on rewrite-clj/paredit and fixing it up the best I can for rewrite-clj users. It might not be entirely practical to use it for an editor (but like you have suggested, it might be good enough!). I see the mismatch between the granularity of the rewrite-clj node vs the granularity of the character in an editor as an awkwardness. I expect you have struggled with this awkwardness already?

yes hehe me and @andreribeirocamargo discussed a lot about the behaviors of forward/backward slurp/barf comparing how all main editors do

Yeah, I've played with emacs to see what it does. I think for questions in my design doc, I could ask: what does emacs do? And use it as a sensible baseline.

That might help.

yes, that sounds good, but I'd suggest checking at least Calva as well, usually they are similar, but some feature or other may differ a little bit (same for Cursive)

And I should also refer to the original ref that the original paredit author used: http://pub.gajendra.net/src/paredit-refcard.pdf

When testing with emacs, there a lotsa choices:

Which do you folks verify behaviour against?

ah, I use paredit-*

Tx, I'll do the same when testing.