In Visual Studio 2008 double clicking in a large section of whitespace would select all the contiguous whitespace only. Now I am using Visual Studio 2010 and double clicking in a large section of whitespace selects the word preceding and the word following the whitespace as well. This makes cleaning up large sections of whitespace more difficult (for alignment or other reasons). Is there a setting or way to get the older behavior?
This issue is killing me... glad I'm not the only one. Misery loves company. Anyway, here's a couple of links of MS acknowledging the issue, and a MS feedback post about it. Bottom line, they "may" try to fix it for the next version of VS. Ouch. It's on the Won't Fix list. The work around is a joke. I hope someone figures out a better fix or work around.
Acknowledgment of issue
Feedback post
This sort-of circumvents the question, but you can do Ctrl+E+D to format the document or Ctrl+E+F for format the selection (which removes the need to select any whitespace).
You can use the shortcut MAJ + HOME to reproduce the desired behaviour. I know it makes you use the keyboard, but you get used to it, and sometimes it's even helpful.
I know its not really a real solution but I can't write comments yet.
Related
When placing the curser on a closing bracket in c# for instance, there is a small annoying delay before the opening bracket gets highlighted, and you have to sit and wait before you can use shortcuts such as (ctrl + shift + up/down). It feels like it is intended behaviour for reasons beyond me, so i don't think it is a bug or because my computer is slow (it's not), but it's driving me crazy.
I'm on a freshly installed PC, so i have only testet it in a few programming languages / file formats, and the behaviour only occours in some of them.
The delayed highligh behaviour occurs in .cs (c#), and .css files, but not in .js and .html files, here the code gets highlighed instantaneously exactly like i want it to in .cs files aswell.
I'm using Visual Studio 2015 Community Edition.
I have had this problem as well, since first installing. I can confirm that Update 1 CTP addresses this issue, and the delay is almost gone (maybe 1/8 second now.)
This UI delay was actually called out as a bugfix that was included with the update:
https://support.microsoft.com/en-us/kb/3025135
To the problem that there is a delay highlighting the brackets: In my opinion that has nothing to do with a bug. I think it takes a little while because your code needs to be parsed every time you change something in order to highlight the brackets. When you have many lines of code in one file it is obvious that it takes a little more time than normal.
Here are some tips that may help you:
Click the bracket and press STRG + ´ this will bring you directly to the other bracket. Or you press ALT + ´ and it will mark all your code in between your current brackets. You can look up the shortcuts of Visual Studio in Tools -> Options -> Environment -> Keyboard:
I'd recommend everybody programming in Visual Studio is to change the highlight color of the matching bracket. Have a look at this:
Here you can change all the colors and forms used for specific searchterms. I personally use Visual Assist 2015 to highlight my code (that's why I didn't change anything here). It is way more faster than VS itself and comes with a lot more functions like bracket guidelines who will show you the indent level of your brackets. Have a look, maybe you like it:
Its about 500ms in a newly created console project
500 msec is a magic number in .NET. You can get some insight from the source code for the C# Language Service, accidentally (?) exposed by a Microsoft programmer on github. Most relevant file is probably this one:
internal interface IBraceMatchingService
{
Task<BraceMatchingResult?> GetMatchingBracesAsync(Document document,
int position, CancellationToken cancellationToken = default(CancellationToken));
}
Or in other words, the brace matching service runs as a background task. Such tasks normally run on a thread-pool thread and are subject to scheduling by the threadpool manager. That's where the magic 500 ms number comes into play. The manager attempts to keep the number of executing tp threads down to the number of processor cores available on the machine, the most efficient way to run threads. However, if the existing tp threads take too long to finish their job then the manager assumes that they are bogged down by I/O and allows an extra one to run. It does this once every 500 msec.
So first-order estimate of your problem is that VS has too many active thread-pool threads and they don't complete in a timely manner. Causing the brace matching task to run too late.
Finding out exactly what specific tasks bog it down is technically possible. I can't guarantee success with the Community edition and you'd need a fair amount of insight in how to read thread call stacks to get ahead. Startup another instance of Visual Studio and use Debug > Attach to Process. Pick "devenv.exe" from the list. Let it trundle while it is attempting to find PDB files, then use Debug > Break All.
First place to look is Debug > Windows > Tasks. Pretty unlikely you'll see anything there however, normal is to see none. Next one is Debug > Windows > Threads. You ought to see about 15 active threads back in that window. Hover over their Location column to take a peek at their callstack. Making sense of what you see isn't that simple unfortunately, it will help a lot if you can compare what you see with another machine that does not have this problem.
Since you have this problem on more than one machine, another approach is to look for an environmental factor that they have in common. Things to look for are aggressive anti-malware, a network connection that is too slow or too unreliable, a poorly performing add-in that you like but runs poorly on a VS version it wasn't tested on.
And consider that VS2015 isn't exactly ready for prime-time. Of all the recent VS versions released in the past 18 years, it is probably the least stable. It has a lot of heavy internal changes and there were an unprecedented number of alpha and beta versions with critical bug fixes implemented just a few months ago. Try it again after Update 1 is released.
Seems like this will be fixed in a future Visual Studio update: https://github.com/dotnet/roslyn/issues/1906#issuecomment-145874647
I have not found a definitive solution for your problem.
This was a known bug in the VS2015 review edition.
This links discusses the delay (this link refers to c# btw, not c):
https://connect.microsoft.com/VisualStudio/feedback/details/1033540/braces-are-not-highlighted-correctly-in-c
And there are still similar problems for some VS2015 Community Edition users.
http://www.developerteacher.com/msdn/bracket-matching-highlights-not-working-like-i-had-in-2013-express-4227
Personally, I think you are stuck with a bug and if I were you I'd try the following:
Make sure I had unistalled all previous editions of VS.
Try a repair.
Completely uninstall and reinstall VS2015 if running repair doesn't work
Go back to VS2013 if it drives you cannot stand it, and wait until VS2015 is a bit more ripe on the vine.
One thing I have found with VS, is when it plays up it's painful, it takes so long to install and the worst case was when I ended up uninstalling and downloading everything that was associated with the install. It now works fine. (this was after previewing 2015 and then going back to 2013). You can also try this for VS2015 and also try a new download.
I sometimes will have a look at some previews, but after jumping in with haste too many times with the latest software releases and then repenting with leisure. I am now happy to wait for new releases to be out for a while before upgrading.
Another FYI for you to browse.
This is a link to Visual Studio 2015 RC fixed bugs and known issues. There are quite a few issues and hacks suggested. (not specific to your problem, but still there a few months ago.).
I am assuming you know how to play around with the settings. I've added the obvious, in case it's been overlooked.
I have added this screen shot from VS2013 settings.
Make sure you have automatic delimeter highlighting checked.
Sorry I could not be of more help.
I'm talking about this guy, right here: λ
In Microsoft Word, you can type 03BB followed by ALT+X to get that character. This does not work in Visual Studio 2013. Any ideas?
To specify: I intend to enter the 'λ' character as part of C# source code, not as part of a string literal.
A good question, and one that bugged me into trying to get this to work. I do second OP's comment that you can compile code with lambda characters for variables just fine.
However, after an hour of trying various methods I knew of and found for typing special characters (using Windows 8.1 Professional, Windows display language set to "English (United States)" and Keyboard layout set to "US") I could not get Visual Studio 2013 (with update 4) to type a lambda.
Although I'm not sure, I'd think that different input languages and/or keyboard layouts would change the situation, and might make this possible.
For the general case, until proven otherwise, I'd hazard a guess that it's not easily possible. The workarounds that probably would work are plugins and unicode-typing-tools. Also, if you already use it, AutoHotkey is probably capable of helping out here.
The easy solution is that copy this symbol "λ" from here and paste it in your VS Code editor. It works!!
I just saw this post on Microsoft Connect(while browsing on /.) about combining tab and indent option into one in VS2010.
They say they did ask here. But I don't see 8 comments being enough.
I usually use the default setting but sometime(in fact rarely) I do use customs settings.
They provide code and say it's our job now to manage these settings.
Final response, for now, from Microsoft;
Thanks again to everyone who has voiced an opinion on this issue. I unfortunately have to reiterate what I posted earlier: we cannot revert the UI for this before RTM. It's too late in the product cycle and too close to the VS 2010 ship date. Had the team heard this feedback a few months ago, the discussion about what to do for VS 2010 RTM could potentially have been reopened; again, we did phase in this change gradually and poll a wide variety of internal and external users to make sure all points of view could be considered before making a final decision. We'll be revisiting this issue for future versions and possibly for a VS 2010 service pack if/when one is to be released, but for RTM we're simply out of time.
Why are they doing this? Anyone know?
Well, the answer appears to be in the thread for your first link:
It's unfortunately not as simple as finding someone who wants a feature to be a certain way. Merging these two options into one eliminated a class of bugs that originated from setting them differently; we didn't consider changing this simply because we felt one fewer text box would constitute a significant improvement. In the absence of a critical mass of users who voiced negative feedback, we made the decision to update the options.
And those 8 comments weren't the only feedback they got, apparently. Quoting yet again:
Regarding user feedback on the decision to merge these two options, we asked a wide variety of people and phased in the changes gradually. We blogged publicly about the potential change on the VS Editor blog (admittedly not the most widely-read VS blog, but readership was significant enough to generate discussion): http://blogs.msdn.com/vseditor/archive/2009/03/19/how-do-you-use-tab-size-and-indent-size.aspx. We solicited feedback from members of Microsoft's MVP program, who spend a lot of time in Visual Studio, and from many internal teams and developers who use Visual Studio. We also phased in the change gradually: for Beta 1, Indent Size was disabled/grayed out and always set to the same value as tab size. In the absence of negative customer feedback on this, we merged the Tab Size and Indent Size options into a single “Tab and indent size” option for Beta 2.
I'm not saying it's a good idea, just that Microsoft appears not to have just inflicted this on their users without at least some consultation. I'm no Microsoft fan-boy in case you think I'm an apologist, other than XP at work, I pretty much use al free software. It just seems to me they may not be totally in the wrong here. And I have had experiences with customers trying to get changes made to software late in the cycle - it's a royal PITA :-)
More worrying to me would be the comment from your second link:
Visual Studio 2010 can support multiple font faces and multiple font heights
Colour and italicise my code all you want, but you'll have to prise my beloved fixed width font from my cold dead hands!
And I've just noticed that MS went out of their way to actually give a workaround to those people who vehemently want the setting kept separate. The comment on the second link, dated Dec 16 2009, gives an editor extension that allows different values to be set for tabs and indents. This is pretty darn good service if you ask me.
EDIT: As you can now see on the Connect bug, we've split the settings back out and I went through and fixed up all the behavior issues with the split options (minus 3 or so bugs that were in the VS2008 implementation, mostly around un-indenting). It won't be patched into the RC, but it'll be there when VS2010 ships.
(I'm a developer on the Visual Studio editor team)
To be accurate, we didn't precisely remove the feature; one of the tradeoffs we made while writing this piece of the new editor was that the cost of reimplementing it, relative to the numerous other things we had to write and what we thought the benefit was, was going to be fairly high. However, we weren't convinced that we had an accurate idea of what the benefit was, so Brittany did all of the things she listed to try and get a better idea of the impact, and again and again we were met with people who really didn't care (the vast majority of people seem to use 4/4). So we disabled it in Beta 1, and didn't get much negative feedback. We removed the option completely in Beta 2, and still didn't get very much negative feedback until the last 2 weeks, at which point it has become too late for us to put it back in (for RTM, at least).
Also, it isn't just a matter of re-enabling the option in the dialog (though that is basically what Brittany's extension does), as the editor itself still doesn't consider indentation/tab size to be different settings (internally, there is just TabSizeOptionId). Though the language services, which generally are the clients that care most about these settings, should handle them correctly, the editor doesn't distinguish between the two, and will end up using the tab size setting in cases where the indent size setting should probably be used.
When I open any code file, whether something i've written or something from another developer, I want it to automatically format it with my preference of bracing, indentation, line spacing, etc..
Ideally, when saving a file to disk, it would only save the formatting for code/lines i've touched. It would still display the rest of the code formatted, however it would not save these to disk (so as to not piss off other developers).
You could use Resharper for this. It will show warnings for formatting inconsistencies (via colored underscores, much like warnings for spellcheckers), and you could instruct it to reformat a selection or a whole file based on either the default formatting rules or your own.
Formatting rules are customizable to fit your own coding standards.
Visual Assist X works for both C/C++ and C#. I use it extensively whenever I have the unfortunate needs to do things in Windows :-).
The refactoring tool is awesome. It fixes Visual Studio smart completion. In fact, after you use Visual Assist X, Visual Studio smart completion looks so dump that you won't believe you paid so much for such crappy "smartness".
Of course, Visual Assist X also adds the much needed snippets. You can finally stop drooling when you see those snippet "special moves" when viewing those Textmate screencasts.
Hmmm, a new odd issue that has just started. Every now and then VS drops a whole bunch of projects from the solution. It will say at the top of Solution explorer "42 projects" when it is displaying only about 20 or so. Closing VS and re-opening it fixes this, although it is a bit of a pain as it takes a little while for the .sln to open again.
We run VS2005 and mainly work on a 42 project solution targetting the Compact Framework 2.00. I'm pretty much the only one using Resharper here (despite my recommendations to others and their occasional oOoing and ahhing at its beauty) so i use CTRL+T to find classes but when i've been hitting SHFT + ALT + L to select the item in the solution explorer (to view the history in TFS) it hasn't matched anything which is how i've noticed this issue.
Anyone experienced this before?
Though this doesn't address your problem directly, have you considered breaking it up into multiple solutions? I'd imagine VS chokes when it starts to get that large, and you're probably working in an un-tested (though not un-supported, I suppose) situation, since I doubt the MS testers created a solution holding 40 projects, all targeting CF.NET.
If you can break it up, that's what I'd advise, and I'll bet the problem goes away. Also, have you tried installing the Service Pack for VS? If not, here it is.
Well this question is super old now and according to my old self:
I think I just rebooted or something and I haven't seen the issue again.
This seems to be about as close as we'll ever get to a solution so I'll set this as the accepted answer for now.