Unexpected behaviour when typing closures (closing pipe not overtyped)

[chrisprice]

I've found the surroundingPairs configuration in language-configuration.json is burdensome when typing closures.

Details

Here's a typical example of the problem I experience -

Notice how the f argument to reduce is automatically selected when I choose to accept the auto-complete suggestion. When I then type | to start a closure, it appears that a closing | has been helpfully inserted trailing the cursor. I then add the arguments and type | again to close the argument list.

My expectation would be that it overtypes the existing closing | (as would happen for a closing ) due to it being one of the autoClosingPairs).

However, instead a third | is inserted forcing me to remove one or other of them.

Documentation Links

• surroundingPairs
• autoClosingPairs

Proposed Fix

Unfortunately I don't think there's a perfect solution to this. The obvious solution of adding | to the set of autoClosingPairs would lead to strange behaviour when using | in specific non-closure contexts (e.g. a | b).

My proposal is to remove | from the set of surroundingPairs to prevent the auto-insertion of the second |.

The negative effect of this would be a change to the existing behaviour. If a user were to make a selection (presumably of the arguments to a closure) and type |, then the current behaviour would be to auto-surround the arguments with |. The new behaviour would be to overwrite the selection with a |.

My personal experience is that I've never attempted anything which would trigger the negative effect but I very frequently (multiple times a day) run into the problem with closures.

Additionally this change would be in keeping with the behaviour of the default Rust language-configuration.json. As best as I can tell, the PR which diverged from this behaviour by adding a custom language-configuration.json makes no mention of why | was included in surroundingPairs.

If there's consensus that this would be a valuable change, I'm happy to create a PR. Alternatively I'm happy to provide more screen captures if that would help clarify either the problem or proposed fix.

[lnicola]

This seems like a good idea, although I think I've trained myself to press the right arrow instead of trying to overwrite a closing pipe.

If a user were to make a selection (presumably of the arguments to a closure) and type |, then the current behaviour would be to auto-surround the arguments with |.

I don't think I've ever wanted to do that, and I don't see myself wanting it.

[cyqsimon]

The negative effect of this would be a change to the existing behaviour. If a user were to make a selection (presumably of the arguments to a closure) and type |, then the current behaviour would be to auto-surround the arguments with |. The new behaviour would be to overwrite the selection with a |.

My personal experience is that I've never attempted anything which would trigger the negative effect but I very frequently (multiple times a day) run into the problem with closures.

It's funny because I distinctly remember many times when I wish | is in surroundingPairs, but now replying under this issue I struggle to come up with even one compelling concrete situation.

I do wonder, if | is to be re-added to surroundingPairs today, would the "failure to overtype" issue still persist? I.e. has there been any changes to vscode since this PR that would allow us to have the best of both worlds?