Say I have my cursor position to the right of a right facing case curly brace, like so:
Now, if I press enter, I expect it to auto align the cursor two tabs in, just like the break statement. But what it does is this:
It adds a ridiculous five tabs! Knowing that Visual studio has a metric ton of settings, I navigate to Tools::Settings::Text Editor::C/C++::Formatting::Indentation, and see the following window:
But changing the highlighted options in any combination actually doesn't affect the indentation at all! None of the other options seem to apply to switch statements, so I don't know what to do. How do I make it not indent 5 spaces, without disabling auto formatting?
And I might add, it not only places 5 tabs when I press enter at the end of the curly brace, but when any auto format event takes place. So when I add a semicolon at the end of a line it places 5 tabs even if I had taken them out before.
This is probably a bit late for you now, but in case someone else finds this issue: it seems to be a Visual Studio bug, you're probably running the freshly installed version of the VS2K13 called REL.
Downloading the Update 4 at http://www.microsoft.com/en-us/download/details.aspx?id=44921 helped in my case.
The curly braces ({ and }) are throwing off the auto-indenter, and it's indenting to one tab beyond the brace.
Braces there are not illegal in a switch statement, but they usually don't do you any good. Unless you need it for scoping a variable declaration, just remove the curly braces. You'll get the same code flow, and you won't confuse the auto-indenter.
EDIT
Come to think of it, you can solve this by simply moving the brace to a new line. This isn't necessarily horrible - it highlights that you're using a brace.
case SDLK_g:
{
// etc
break;
}
I went into VS2013 and created a new project and just tried making a really simple switch but it formatted correctly for me, even with the curly braces. Are you able to post that set of code?
The only other thing I can think of is maybe a setting on how braces are set up, but I don't know why that would affect it. (Nor do I think there is really even a setting for that for C++...) Other than that though you could try just not using the braces at all since you are inside a case statement, you don't technically need them.
Other than that something may have happened during installation. So re-installing is an option too.
EDIT:
Also, could just go with it and finish the code and then when finished just highlight the rows and un-indent ([SHIFT]+[TAB]) them back to their correct spot.
Related
What is this weird syntax you can use the the watch window (or even to set breakpoints) and where can I find it documented:
{,,test2.exe}<variable name>
When starting the program, the first will translate to my entry point and will break on execution start.
Intuitively I can see what this means, but where is it documented and what are the leading commas for (what stuff can you put in there)?
Why does using the syntax in the watch window help?
As the VS2015 documentation states, that is called a Context Operator, valid only for C++ native applications.
You could put function and source file before the first and the second comma.
For VS2010 and previous versions the documentation is slightly different and more verbose.
I'm transitioning to Visual Studio 2010 from version 2008 and have noticed several differences between the editor. Most I have fixed or found work-arounds for. One feature that I cannot get to work like it did in 2008 is when I type an open curly brace "{" on a non-empty line in a CPP file. Typically, after starting a for, if, while, or similar statement, I'll automatically type the {} on separate lines below the statement so that the curly braces are nicely lined up (it's an OCD thing). VS 2010 does what I want in this situation.
if (varIsTrue)
{
varIsTrue = false; // typed after the initial {} pair.
// do something really innovative here...
}
It's when I forget that initial "{" that the editor no longer wants to help.
if (varIsTrue)
varIsTrue = false;
Oops. Forgot the curly brace (or I simply need to create a code block for additional code.)
Typing a "{" gives
if (varIsTrue)
{varIsTrue = false;
instead of
if (varIsTrue)
{varIsTrue = false;
so that hitting ENTER will properly indent "varIsTrue = false;"
Visual Studio 2008 handled this correctly, but 2010 does not. I've yet to find a way fix this in the editor options, and I assume that an editor extension would be the only other option.
So basically, if there is a way to fix this in the editor, how can I do it? If not, does an extension exist that would allow me to fix the problem?
Interestingly, this problem does not exhibit itself in a C# file, so I am hoping there is a way to fix it for CPP files.
I appreciate any help regarding this.
Visual Studio 2013's new feature, 'Auto Brace Complete', is quite useful, but I feel I have not unlocked its full potential to make it more useful.
So if I wanted to type newstr="Hello World" + oldstr;, before the 'Hello World' is typed in, the closing quotation mark is already typed in after the words. Now, how should I tell VS2013 that I finished typing in the braces so it can know that I want to leave the braces and go on to the next part?
In other words, for the above example, what is the expected behavior in step 4?
newstr=
"
Hello World
???
+ oldstr;
Should it be another " key? That seems to defeat the purpose of using auto braces.
Should it be the right arrow key then? But, that key is far from the typing area, so I might as well just use " instead.
Enter key or Shift+space seem like the logical choice to me, but neither works as I intended.
Can anyone shed any light on this issue? Thank you.
Press tab to jump outside of the quotes.
Just typing the closing quotation marks " is exactly what is expected. They only serve as a visual aid, or when you're inserting a string literal in the middle of a line.
Should it be another " key? That seems to defeat the purpose of using auto braces.
Why is using " the wrong key? Auto-braces provides 2 things to the editing experience:
Inserts the closing braces so you don't have to (in this case, you only had to type the opening quote)
Makes it easy to move past the closing brace (or quote) without having to use the arrow keys or mouse. As you correctly pointed out, the arrow keys are inefficient when typing because you have to move your hand away and back. Typing another " is a much faster way to move the cursor, and it will do the Right Thing and just move the cursor forward instead of typing an unwanted ".
Background
I use JScript (Microsoft's ECMAScript implementation) for a lot of Windows system administration needs. This means I use a lot of ActiveX (Automated COM) objects. The methods of these objects often expect Number or Boolean arguments. For example:
var fso = new ActiveXObject("Scripting.FileSystemObject");
var a = fso.CreateTextFile("c:\\testfile.txt", true);
a.WriteLine("This is a test.");
a.Close();
(CreateTextFile Method on MSDN)
On the second line you see that the second argument is one that I'm talking about. A Boolean of "true" doesn't really describe how the method's behavior will change. This isn't a problem for me, but my automation-shy coworkers are easily spooked. Not knowing what an argument does spooks them. Unfortunately a long list of constants (not real constants, of course, since current JScript versions don't support them) will also spook them. So I've taken to documenting some of these basic function calls with inline block comments. The second line in the above example would be written as such:
var a = fso.CreateTextFile("c:\\testfile.txt", /*overwrite*/ true, /*unicode*/ false);
That ends up with a small syntax highlighting dilemma for me, though. I like my comments highlighted vibrantly; both block and line comments. These tiny inline block comments mean little to me, personally, however. I'd like to highlight those particular comments in a more muted fashion (light gray on white, for example). Which brings me to my dilemma.
Dilemma
I'd like to override the default syntax highlighting for block comments when both the beginning and end marks are on the same line. Ideally this is done solely in my vimrc file, and not in a superseding personal copy of the javascript.vim syntax. My initial attempt is pathetic:
hi inlineComment guifg=#bbbbbb
match inlineComment "\/\*.*\*\/"
Straight away you can see the first problem with this regular expression pattern is that it's a greedy search. It's going to match from the first "/*" to the last "*/" on the line, meaning everything between two inline block comments will get this highlight style as well. I can fix that, but I'm really not sure how to deal with my second concern.
Comments can't be defined inside of String literals in ECMAScript. So this syntax highlighting will override String highlighting as well. I've never had a problem with this in system administration scripts, but it does often bite me when I'm examining the source of many javascript libraries intended for browsers (less.js for example).
What regex pattern, syntax definition, or other solution would the amazing StackOverflow community recommend to restore my vimrc zen?
I'm not sure, but from your description it sounds like you don't need a new syntax definition. Vim syntax files usually let you override a particular syntax item with your own choice of highlighting. In this case, the item you want is called javaScriptComment, so a command like this will set its highlighting:-
hi javaScriptComment guifg=#bbbbbb
but you have to do this in your .vimrc file (or somewhere that's sourced from there), so it's evaluated before the syntax file. The syntax file uses the highlight default command, so the syntax file's choice of highlighting only affects syntax items with no highlighting set. See :help :hi-default for more details on that. BTW, it only works on Vim 5.8 and later.
The above command will change all inline /* */ comments, and leave // line comments with their default setting, because line comments are a different syntax item (javaScriptLineComment). You can find the names of all these groups by looking at the javascript.vim file. (The easiest way to do this is :e $VIMRUNTIME/syntax/javascript.vim .)
If you only want to change some inline comments, it's a little more complicated, but still easy to see what to do by looking at javascript.vim . If you do that, you can see that block comments are defined like this:-
syn region javaScriptComment start="/\*" end="\*/" contains=#Spell,javaScriptCommentTodo
See that you can use separate regexes for begin and end markers: you don't need to worry about matching the stuff in between with non-greedy quantifiers, or anything like that. To have a syntax item that works similarly but only on one line, try adding the oneline option (:h :syn-oneline for more details):-
syn region myOnelineComment start="/\*" end="\*/" oneline
I've removed the two contains groups because (1) if you're only using it for parameter names, you probably don't want spell-checking turned on inside these comments, and (2) contained sections that aren't oneline override the oneline in the container region, so you would still match all TODO comments with this region.
You can define this new kind of comment region in your .vimrc, and set the highlighting how you like: it looks like you already know how to do that, so I won't go into more details on that. I haven't tried out this particular example, so you may still need a bit of fiddling to make it work. Give it a try and let me know how it goes.
Why don't you simply add a comment line above the call?
I think that
// fso.CreateTextFile(filename:String, overwrite:Boolean, unicode:Boolean)
var a = fso.CreateTextFile("c:\\testfile.txt", true, false);
is a lot more readable and informative than
var a = fso.CreateTextFile("c:\\testfile.txt", /*overwrite*/ true, /*unicode*/ false);
I have looked at the following question:
How to comment out a block of Python code in Vim
But that does not seem to work for me. How do I comment code easily without resorting to plugins/scripts?
Use ctrl-V to do a block selection and then hit I followed by //[ESC].
Alternatively, use shift-V to do a line-based select and then type :s:^://[Enter]. The latter part could easily go into a mapping. eg:
:vmap // :s:^://<CR>
Then you just shift-V, select the range, and type // (or whatever you bind it to).
You can add this to your .vimrc file
map <C-c> :s/^/\/\//<Enter>
Then when you need to comment a section just select all lines (Shift-V + movement) and then press CtrlC.
To un-comment you can define in a similar way
map <C-u> :s/^\/\///<Enter>
that removes a // at begin of line from the selected range when pressing CtrlU.
You can use the NERD commenter plugin for vim, which has support for a whole bunch of languages (I'm sure C++ is one of them). With this installed, to comment/uncomment any line, use <Leader>ci. To do the same for a block of text, select text by entering the visual mode and use the same command as above.
There are other features in this such as comment n lines by supplying a count before the command, yank before comment with <Leader>cy, comment to end of line with <Leader>c$, and many others, which you can read about in the link. I've found this plugin to be extremely useful and is one of my 'must have' plugins.
There's always #ifdef CHECK_THIS_LATER ... #endif which has the advantage of not causing problems with nested C-style comments (if you use them) and is easy to find and either uncomment or remove completely later.