[command] cursor does not follow slurp and barf

[johanatan]

... so subsequent slurps and barfs are harder than need be; i.e., repeated slurping or barfing is clumsy.

[I'm not quite sure which paredit, parinfer, etc setup Spacemacs has out of the box but this particular feature would be a nice to have].

[sooheon]

Not sure what the problem is with default, but I highly recommend the evil-cleverparens layer, and also looking into lispy (not a layer yet). They both have good parens wrangling.

[TheBB]

Can you provide an example? I haven't experienced any problems.

[johanatan]

Put your cursor on a closing brace. Invoke 'slurp'. Notice that the cursor does not follow the brace (although you can still press 's' additional times for consequent slurps). It would be easier to follow if the cursor actually followed the brace being moved (and I have seen others' emacs setups do this).

[TheBB]

You should report this to smartparens then.

[johanatan]

I realized that it is probably intentional and have in the meantime adjusted to the behavior. Having used someone else's emacs for a while before my own, I was accustomed to the other behavior (and still think it is better) but I have no idea how the other emacs was setup and am pretty sure the smartparens guys would not welcome this behavior change request.

[johanatan]

@TheBB Do you know the project link for smartparens? I am experiencing an even worse effect with barf. If you barf once, a subsequent keypress on 'b' does not continue to barf more forms from the just initiated form but will rather interpret it as a new barf on whatever (likely ending brace) char ends up under the [non-moving] cursor. This is very strange (and unhelpful) behavior.

Could SpaceMacs consider using a different smart parenthesis library (such as paredit or parinfer)?

[TheBB]

https://github.com/Fuco1/smartparens

[johanatan]

Thanks. What about the second part of my question?