Just came across this randomly and wanted to record it before it gets lost in the void. In the gif below, I type (.then) and then hit the shortcut for slurp sexp forward (and that's it). You can see the # stays next to .then and the cursor for some reason jumps backwards out of the list.

Good recording. Looks like it could be a more general root cause there, but my brain hasn't started yet, so can't really grasp it.
I have a request for you, @bpringe . 馃槃 These images and gifs are very good for showing what is going on. To go with them I want to have the text as well. It's easy to get it wrong when retyping it.
Anyway, I just tried this. It is the formatting that is causing the invalid syntax. Or, rather, it is at the formatting step that this happens. Like so:
(foo|)#()(foo|#())foo# followed by a list and formats it, adding whitespace: (foo# ())Not sure where the cursor displacements happen, doing thie formatting step in isolation doesn't provoke it. But it seems it happens after the formatting, because the enclosing list does not get formatted when slurping. If we check what it is the formatter gets as input we might be able to pinpoint this.
Not sure what the fix is here. Maybe adding a space where the opening paren were as part of the slurp...
I'll try to remember to provide the text next time :smile:
Maybe adding a space where the opening paren were as part of the slurp...
I think this would actually make sense. Without having thought about it much, it seems like in any case, if slurp is performed and the thing immediately before the cursor is _not_ an open/close token (and maybe some other things?), then a space can/should be placed there.
[|]1 - no space should be placed before the cursor when slurping forward because the token before it is [[1|]2 - a space should be placed before the cursor when slurping forward because the token before it is 1These are just a couple of examples to demonstrate. We'd need to spend some time thinking about other cases.
And also the same thing for slurping the other way, of course.
Since we format after the slurp we can probably add the space unconditionally and rely on the formatter to clean up extraneous whitespace.
Seems I was not completely right about that...

Is this something to be fixed in the formatter? I mean should the formatter remove extra spaces in that situation?
It is that we use on-type formatting options here. I don't think we should, but I am not sure. Will cook a PR that we can test a bit and see if it behaves.
on-type formatting does not trim surrounding whitespace. Maybe that wasn't clear in my previous comment...