I'm currently writing php-code in Eclipse 3.02 and a tiny but irritating bug/feature has popped up. When I change line after an opening curly brace { the marker always jumps to column 1, forcing me to manually tab to get the correct indentation. I have only experienced this whith opening curly braces. If I don't use open braces (i.e. press enter after else, for or closed curly brace }) it indents correctly. Is this a known error and is it solvable?
Make sure you got Statements within block selected (and all other situations you want automatic indentation).
Related
I'm using the Groovy editor in Eclipse. When I compile/seed my script I sometimes get the below output.
839: expecting '}', found '' # line 839, column 1
The line above is the last line in the script which doesn't tell me much. It just says there is a closing brace missing somewhere in the script. One way I typically try is to zoom out (ctrl -) as much as possible in my editor (after source code formatting) then I try to look for something that looks oddly indented. The problem is some blocks are quite long so this is not ideal...
Is there a better approach or easier way to find out where the missing brace is in Eclipse? Or using another app (i.e. Notepad++, Sublime)? I would like to avoid using online tools pasting sensitive code.
When you place the cursor after an opening brace, the editor will highlight the closing brace. And you can jump to the closing brace using Go to Matching Bracket (Ctrl+Shift+P). Similarly, you can place the cursor just before a closing brace to highlight the opening brace and use the same command to jump to it. Using these aids, you should be able to narrow down where the unpaired opening brace is.
This has been annoying me for a while. VSCode doesn't let me type a closing bracked or parenthesis or the like ( ")", "]", "}") when there is already a closing symbol of the same type.
In this WEBM you see me try to set another set of brackets and VSCode skips the closing bracket that I typed. This is extremely annoying.
WEBM
How do I disable this behaviour in VSCode? (Or correct it, so VSCode closes the inner bracket for me.)
Edit: I know I can disable auto closing brackets in VSCode with "editor.autoClosingBrackets": false. But I don't want to disable it altogether. I just want to disable the overtyping.
TL;DR: As of June 2019, it's not possible to disable only the overtyping part of the autocloseBrackets function. You can only disable auto
bracket closing altogether.
Some people suggest using the TabOut Extension for Visual Studio Code to tab out of quotes, brackets, etc.
Ok, so what I found out over at the VSC Github is this:
[...] This can be turned off via editor.autoClosingBrackets. The feature
consists of multiple parts:
one is that when ( is typed, the result is (|).
the other part that is hit here, is that when ) is typed and ) follows the cursor, ) will be overtyped.
The feature is implemented language agnostic and looks only locally at
the next character. It does not count brackets to determine if the
code is "bracket unbalanced".
(Source: https://github.com/Microsoft/vscode/issues/35799)
At the moment, it's not possible to fix this, without losing the auto
bracket closing feature. The above thread has since been closed. New one is here: https://github.com/Microsoft/vscode/issues/37315 , but no patch has come out yet.
I face the same issue,
It's because of the GIT COPILOT once I uninstall and restart the VS CODE it's working properly now
In Atom I can select inside of brackets with CMD+CTRL+M. How can I do this in Visual Studio Code? I've checked the keyboard bindings, but didn't find anything.
There are 2 even better alternative commands in the keybinding file you might want to check out:
editor.action.smartSelect.grow
and
editor.action.smartSelect.shrink
They select everything in between the next boundary (quotes, brackets, curly braces...) and the selection grows to the next boundary when you hit the shortcut again.
Default shortcut is ctrl+shift+cmd+right / ctrl+shift+cmd+left, which is a bit too "finger heavy" for my taste, so you might want to rebind it (I use ctrl+up / ctrl+down).
Shift+Alt+Right for selecting all text inside the braces.
CTRL+Shift+\ for jumping between opening/closing braces (or) parentheses.
I'm using Netbeans 7 and programming PHP. I was wondering if anyone knew of a keyboard shortcut to jump out of quotations marks and parenthesis (besides the right arrow key). For example I would like to type a quotation, type some text, then:
"my cursor would be here -> |"
Then hit tab or something equivalent to jump outside of the quotations:
"some text"| <- my cursor would now be here
Is this possible to accomplish using netbeans?
Type the second (end) quote. Netbeans realizes what's going on and does exactly what you describe.
you should take the auto quotation as a help to minimaze errors:
"The user often writes a code that has opening and closing brackets, and this is very often source of compilation errors. If the IDE would insert a closing bracket each time opening bracket is typed, the likelihood of error is smaller, and the user also has a better visualization of the structure."
source: https://ui.netbeans.org/docs/hi/promoB/smartBrackets.html
I was looking to a "short cut" myself to allow me to jump outside the quotation even when the cursor is not at the end of the content, but I could not find it.
Like me, you might find this method useful as well: select the text you want to wrap in quotes/brackets and the press the opening quotes/brackets you like: NetBeans will do it for you.
source: How to surround a text in quotes in netbeans IDE
code safe ;)
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):
Is it possible to change this behavior?
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.
Try setting:
"editor.autoClosingBrackets": "never"
to disable the autoclosing brackets feature entirely.
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.
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)
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.