37

When I try to add closing parentheses, it always override the next parentheses to the right.

Here is a screen capture (it looks like I hit the right-key on the keyboard, but I'm actually inserting a new closing parentheses):

enter image description here

Is it possible to change this behavior?

niryo
  • 1,275
  • 4
  • 15
  • 26

5 Answers5

16

As of version 1.38, the answer is yes, you can turn it off completely, while still keeping the autoclosing brackets.

That version introduced a new setting, editor.autoClosingOvertype, which can take three possible values:

  • always - always overtype closing parens (the old, classic, Sublime-Text-inspired behavior)
  • auto - "smart" overtype which tries to detect whether a closing paren was automatically inserted by the editor, and overtypes only those parens (this is the default)
  • never - never overtype closing parens

The current default behavior was introduced in version 1.37. At that time, there was no setting available, you just got the "smart" overtype behavior no matter what.

I'm leaving the material below for historical purposes.

No, it's not possible (yet), and this is by design. When you are typing brand-new code, and you type an opening bracket, you get the closing bracket automatically (when you have editor.autoClosingBrackets on, of course). Then, when you are finished with typing whatever you want inside those brackets, how are you going to "exit" and leave the closing bracket where it is? The most natural way is to type a closing bracket! Some disagree, but many typists find this much easier than moving their hand all the way out to the arrow keys or mouse to move past it.

Note that this behavior is largely inspired by and modeled after what Sublime Text does.

It may be helpful to understand that the autoclosing brackets feature isn't primarily for saving keystrokes. Rather, its main purpose is to improve the stability of syntax highlighting (which can get wonky when there is an unclosed bracket), and secondarily to help prevent you from forgetting to type the closing bracket. If you happen to navigate away for some other reason without typing it, then congratulations, you do get that bracket for free!

The two simplest options you have if you want to add a bracket (and let me note that in your example, you'd be adding a mismatched bracket) are to either (1) put the cursor after the cluster of closing brackets before you type a new bracket, or (2) put the cursor where you did, but just keep typing closing brackets until a new one is added. In either case, any new brackets will only be added to the end of the cluster.

Update (now obsolete):

For what it's worth, there's now an issue for this on the tracker, as well as a pull request to create a setting which allows you to turn off the "bracket-swallowing". For anyone who is reading this, if it's something you're interested in, you should give your feedback on the pull request.

Further update (now obsolete):

There is currently new code being tested which will make the bracket overtyping more sophisticated. The plan is for the editor to keep track of which brackets have automatically been generated, and only type over those brackets. Once the cursor leaves the bracketed area, the editor stops keeping track of those brackets and they become "full-fledged" characters that can no longer be typed over. Hopefully, this will retain the overtyping where it's useful and get rid of it where it's not. Note that the current plan is for this new behavior to become standard, and to not have a setting to control whether it is in effect.

John Y
  • 14,123
  • 2
  • 48
  • 72
  • 12
    The feature makes total sense, it's just the implementation is too naive to be useful. It doesn't verify if brackets match so it makes it harder to add *missing* parenthesis. – Álvaro González Nov 02 '18 at 09:54
  • @ÁlvaroGonzález - I hear what you're saying, but I am not sure that there *is* any "smart" way to handle this. Just checking whether brackets match wouldn't be sufficient to handle all reasonable cases. And if your software can't read your mind, the next best thing is for your software to have easily definable, predictable behavior (even if it's naive), so that *you* can adjust to it. If you simply cannot get used to the feature, in this case you can fortunately turn it off completely. (Personally, I have it turned off, but for other reasons.) – John Y Nov 02 '18 at 18:45
  • 7
    I find these auto-closing helpers more of a hinderance than being useful. Especially when you need to go back and split an `if` into a nested `if` or various other instances where you want to modify some existing code. It's usually never a problem when typing code for the first time. I turn all three of these off: `"editor.autoClosingQuotes": "never"`, `"editor.autoClosingBrackets": "never"`, and `"editor.autoSurround": "never"`. – wsams Mar 25 '19 at 20:41
  • @JohnY it's a huge mistake to base a feature on one's own perspective, then try to "teach" the masses to do something differently. It's even worse if you're not one of the developers and just "drank their kool-aid" for the heck of it, then try to get others to do the same. Going off topic so I'll stop. No offense it's just a non-answer. I'm having issues because I spend a great deal of time editing someone else's (or my own) parenthesis after the fact and I keep getting unmatched parenthesis errors in Angular because the editor didn't follow my lead. – Dan Chase Apr 06 '19 at 18:59
  • @DanChase - I hope you are not saying that I am trying to get people to do anything. I was just trying to explain the rationale behind the feature because often that is helpful in terms of either learning how to cope with it or deciding to choose another editor. You should also be aware that VS Code simply copied this behavior straight from Sublime Text, which was a very popular and highly regarded editor long before VS Code came into existence (and it still is). So clearly there is some user base out there that likes and expects it (and is even willing to *pay for it*). – John Y Apr 08 '19 at 13:56
  • @JohnY Sorry if it sounded like I was attacking you personally, reading it again today I can see why it could be interpreted that way. Interesting history with VS code and Sublime! It looks like you can disable but mixed results. Thanks again for the explanation. – Dan Chase Apr 08 '19 at 19:00
  • I assume this usually happens when trying to wrap existing code on brackets (or braces, or quotes). If you can change your workflow VScode will insert both brackets at the same time. Highlight the block you want to wrap in brackets and type `(`. Instead of overwriting the highlighted text VSCode wraps it in `(` and `)`. – BetaKeja Jul 16 '19 at 17:58
15

Try setting:

"editor.autoClosingBrackets": "never"

to disable the autoclosing brackets feature entirely.

Moghul
  • 3
  • 1
Matt Bierner
  • 58,117
  • 21
  • 175
  • 206
  • 20
    Technically speaking, it solved my problem...but I actually like the autoClosing feature. I just don't like the auto override thing. – niryo Aug 09 '17 at 07:48
  • 11
    I agree with OP (kundasaba); i.e. I like auto-closing when adding '(', but dislike omitting ')' when I type a ')'. It's really problematic when editing existing code with lots of nesting. Also, auto-close doesn't seem to work when adding '(' when not in the inner-most '(' / ')' pair. – Apriori Apr 19 '18 at 22:02
  • 2
    I changed this, but it has no effects. Even after restart. This is driving me crazy :( – Yan King Yin Feb 12 '19 at 02:28
2

Vscode has finally fixed this issue, and you don't need to do anything in order to get the new behaviour. Now it will swallow only brackets that were automatically added, so everything works as expected. If you already disabled the autoClosingBrackets option from the settings, it is recommended to turn it on again now.

niryo
  • 1,275
  • 4
  • 15
  • 26
  • 1
    Are you having a bug with function calls or did they introduce a setting to fix it there? It works as expected for me besides when I intellisense a function and then it inserts the opening paren, but upon close it inserts another one instead of skipping over it – kalenpw Aug 12 '19 at 16:26
  • I am not sure I understood your question. Anyway, until few weeks ago, if you tried to insert a closing bracket, the bracket would have been swallowed (look at the gif in the original question). now they fixed this behaviour and you don't need to change anything in the settings. – niryo Aug 13 '19 at 13:16
  • Some people may find that they still *never* want *any* brackets to be swallowed. The latest version allows you to choose that behavior if you want (see my updated answer). – John Y Sep 25 '19 at 15:34
1

There's another option available now called autoClosingBrackets beforewhitespace. This will overtype an automatically added parenthesis but it will not overtype of there's any characters to the right of that closing parenthesis. This is perhaps a step closer to the OPs intended behavior, it certainly saved me from going totally bald.

search autoClosingBrackets in settings

Andy Gee
  • 3,149
  • 2
  • 29
  • 44
0

The way to work with the VSCode original setting is to add new parenthesis at the end of a list of parenthesis.

...if (test === funFunction(data))| /* <- here */ {...

You should be able to type a new parenthesis and it won't override the old one. This doesn't solve your problem, but if you wanted to follow the paradigm that VSCode is using then there you go.

(personally I disable it like the other comments say)

Matt Wyndham
  • 371
  • 3
  • 6