Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slurping anonymous function shorthand causes invalid syntax #883

Closed
bpringe opened this issue Dec 22, 2020 · 9 comments
Closed

Slurping anonymous function shorthand causes invalid syntax #883

bpringe opened this issue Dec 22, 2020 · 9 comments
Labels
bug Something isn't working paredit Paredit and structural editing

Comments

@bpringe
Copy link
Member

bpringe commented Dec 22, 2020

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.

slurp-function-shorthand

@bpringe bpringe added bug Something isn't working paredit Paredit and structural editing labels Dec 22, 2020
@PEZ
Copy link
Collaborator

PEZ commented Dec 22, 2020

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.

@PEZ
Copy link
Collaborator

PEZ commented Jan 4, 2021

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:

  1. The cursor is at the end of the list before the anon fn: (foo|)#()
  2. Slurp forward moves the closing paren to the right of the anon fn: (foo|#())
  3. The formatting sees a list with the symbol 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...

@bpringe
Copy link
Member Author

bpringe commented Jan 4, 2021

I'll try to remember to provide the text next time 😄

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 1

These are just a couple of examples to demonstrate. We'd need to spend some time thinking about other cases.

@bpringe
Copy link
Member Author

bpringe commented Jan 4, 2021

And also the same thing for slurping the other way, of course.

@PEZ
Copy link
Collaborator

PEZ commented Jan 4, 2021

Since we format after the slurp we can probably add the space unconditionally and rely on the formatter to clean up extraneous whitespace.

@PEZ
Copy link
Collaborator

PEZ commented Jan 4, 2021

Seems I was not completely right about that...

creeper

@bpringe
Copy link
Member Author

bpringe commented Jan 4, 2021

Is this something to be fixed in the formatter? I mean should the formatter remove extra spaces in that situation?

@PEZ
Copy link
Collaborator

PEZ commented Jan 4, 2021

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.

@PEZ
Copy link
Collaborator

PEZ commented Jan 4, 2021

on-type formatting does not trim surrounding whitespace. Maybe that wasn't clear in my previous comment...

@PEZ PEZ mentioned this issue Jan 4, 2021
20 tasks
@bpringe bpringe closed this as completed in 4230f10 Jan 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working paredit Paredit and structural editing
Projects
None yet
Development

No branches or pull requests

2 participants