I know that sound like a stupid question, and we can find many answer on google.
However, i've been trying for one hour and it still not working.
The question is prety simple, i'm coding on visual studio code on Mac OS.
And i want to instert tab when i press tab, and not 4 spaces.
It it supposes to be very simple :
Go on "code"->"preferences"->"users stting"
And add :
// Insert spaces when pressing Tab.
"editor.insertSpaces": false
Into : settings.json
However i have no clue why, but this is not working.
(I've save it, close visual, reboot mac, still not working)
Does anyone has any clues to help me?
Thanks a lot.
(I've save it, close visual, reboot mac, still not working)
--> One thing is missing - did you try it with a completely new file? ;)
I just tried it, had the same issue and almost thought it is a bug, but it seems to be expected behavior as there is another setting editor.detectIndentation which is true by default.
If the indentation is detected then the detected value takes precedence over your defined setting. At first this seemed odd as others also reported in a GitHub issue. But the analogy with CR/CRLF in this issue makes sense.
So as a quick fix you could set editor.detectIndentation to false or convert your existing indentation to tabs so that the next time you open the file the proper detection is done.
Visual Studio 2015 Community
So I am new to Visual Studio completely. It works perfectly on my desktop, but I am having this problem on my laptop. Here is the gist of it -
I just write something to print the numbers 0 - 10. If I hit F5, it builds and flashes on the screen real quick, as expected. Next, I hit Ctrl F5 - cmd opens and is blank, just the flashing line. It does not run. I close the cmd window (have tried just hitting return/any key on the blank window). After closing, if I try to run it again, either F5 or Ctrl F5, I get the error:
Could not copy "obj\Debug\ConsoleApplication2.exe" to "bin\Debug\ConsoleApplication2.exe". Exceeded retry count of 10. Failed.
I have looked around for a solution and even though both of these separate issues are talked about, cannot find any solution to either of them.
If I go to task manager, I have several ConsoleApplication2.exe*32 processes - I can kill all of them but two. No matter what I do I cannot terminate them, and cannot delete the src/bin folders as I saw someone suggest.
Further, even if I figure out how to kill these processes so I can run again, it still doesn't help me with why Ctrl F5 just doesn't run.
Can anyone help or point me in a direction to a possible cause for this? I tried repairing, uninstalling and reinstalling, and several other suggestions and nothing seems to work. I am going crazy trying to get this to work.
I think it's your anti-virus .. especially if you're using Avast. It causes the same issue for me.
To solve it add exclusion to your anti-virus:
When I am programming in Xcode (in C), and I am using the debugging console (brought forth with Cmd-R) to view the program and its output, and give it input, when I am entering input only the first character that I want to input shows up on the console. All the rest are invisible and non-selectable to me. Say I want to enter "20": all that shows up is "2". It still behaves as though I had entered all those characters (in the previous example, 20), so technically this bug (?) doesn't interfere with the actual software, but it's still annoying not to see all of the keystrokes that I had inputted previously. I just updated Xcode a day or two ago and installed Command Line Tools as well (though I doubt the latter is relevant). I believe the version number is 4.3 or so. Is anyone else having the same problem, and has anyone found a fix? Yes, I've tried restarting it.
I have the same problem.
It looks like it's a XCode 4.5 bug:
https://discussions.apple.com/message/19701332?tstart=0#19701332?tstart=0
So, you can wait or install a previous version.
I experience a quite strange behavior in TextMate since some time.
I had troubles to use the keyboard shortcut for commenting a line (which is Cmd-/ or on my swiss layout it is CMD+SHIFT+7 where SHIFT+7 results in a /) a few times already since I switched to Lion 2 months ago (before I never had any problems). I then used to restart TextMate and it worked again.
But now, restart doesn't solve the problem. So I went into the Bundle Editor and tried to reset the shortcut, and there I can set it to anything I like, but not to Cmd-/! Nothing happens when I want to record the shortcut and press CMD+SHIFT+7`, the input field stays blank!
I have some bundles installed since my switch to Lion (Cucumber, RSpec, RubyAMP, Ruby Debug, Shoulda), so maybe one of those makes troubles?? Or does the fact that I even don't seem to be able to send CMD+SHIFT+7 in the Bundle Editor imply that the Shortcut is blocked from somewhere else "outside" of TextMate?
How should I debug this? Thanks for help.
Turns out it was Skitch that was running and occupied Cmd-Shift-7.
I'm running Visual Studio 2010 with SP1, as well as R# 5.1, and a few other extensions (like PowerCommands and Productivity Power Tools). Somewhere along the lines, my debugging got super slow. If I use the F10/F11 keys to step, VS hangs for a bit and then steps. If I use the toolbar buttons for stepping, it's snappy as expected.
Any idea what's up with my shortcut keys?
I had exactly the same problem - extremely slow debugging with keyboard (F10 for example). Some symptoms:
if I click Step Into on toolbar, then everything works normal,
the lag during debugging is present not only in Visual Studio but anywhere (notepad, browser,...),
if I set any other browser as default browser in Visual Studio (I tried Firefox), then it works OK,
if I disable third-party browser extensions in IE, then it works OK,
if I enable third-party browser extensions and disable LastPass, then the problem is gone and debugging with keyboard is fast again!
So, try to disable LastPass extension if you have it or all extensions and try it.
Edit1 - somebody allready posted this on LastPass forum: http://forums.lastpass.com/viewtopic.php?f=12&t=61029
Edit2 - and here on SO also :) https://stackoverflow.com/a/8186670/1110039
I've found a deeper explanation for this problem.
I had this problem, with the symptoms user1110039 described BUT I haven't installed LastPass toolbar. And my default browser is Firefox.
Well, my application uses SetWindowsHookEx() function for setting a system wide shortcut. Which happens to be the reason for blocking F10/F11 debug keys (only in Windows 7 64 bits) It doesn't happen under 32 bits.
I've just removed the hook from the debug build and it works ok. I reckon the problem with LastPass is some system wide hook in the code of the extension.
I had exactly the same problem.
The problem was solved by closing the Watch window.
Try debugging with Firefox or Chrome. There must be something about the interaction with IE that is causing this behavior.
Disable "show threads in source" worked for me!
Calling DirectInput's Acquire() function on a keyboard device is what caused the slowdown for me. This is potentially related to the SetWindowsHookEx() caused slowdown - ie. that might be using DirectInput.
It's really odd that the keyboard stepping is slow while the toolbar buttons are not. Typically whenever I hear about a slow stepping experience my recommendation is to disable automatic property and ToString evaluation as this is the most likely cause
Tools -> Options
Debugger -> Uncheck "Enable property and .ToString evaluation"
I'm not very hopeful that will fix this instance. It sounds like a problem with a misbehaving extension that processes keyboard input. Your best bet is to disable the extensions one by one and see which one fixes the problem. I would do it in the following order
Productivity Power Tools
Power Commands
R#
Make sure you've installed Service Pack 1. I believe they fixed at least one significant performance problem in the debugger.
I experienced that very slow step by step debugging too, and fixed it by closing the threads window.
(Making a note here on an old thread, so it can be found in a web search.)
I normally leave the ==Disassembly== window open during debugging (I have a big screen.) I just discovered that single-stepping in the debugger can be speeded up by 50% if I hide that window too. The -tab- for it can exist and be handy - makes no difference - but the window itself shouldn't be showing. Ahah.
Have followed all the other suggestions and more from elsewhere, single-stepping is now about 8 times faster overall. (About 2.5 steps per second now.) Woo-hoo! Thank you all.
(I don't understand how they can write such slow UI code... I have a CPU here that's running at two billion cycles per second... that works out to about 400 million instructions per single step. Seems like Microsoft code could be a -little- faster... but then, I've never had the pleasure of using .NET etc.)
I tried all the suggestion and finally found that When I uninstalled VS2005, this issue got resolved. Note that in that machine VS2005
I was having this problem in my new job, where we use Visual Studio 2008 SP1. (Yes, I know, I know). Long delay on step with flickering hourglass. I always use F10, I don't even think about it, there's no way I could tolerate changing to the mouse or waiting multiple seconds for a simple step command.
I read through all the solutions provided here and elsewhere on the net with no joy.
Finally found the issue - I had set up my default language for the IDE as C#. It turns out the project I'm working on actually uses VB.NET, and when I set the default language to VB.NET (via Tools - Import and Export Settings) the debugger got so fast that I couldn't keep up with it and accidentally pressed F5 on the breakpoint I want to examine.
I hope this helps someone else.
In the end, the disabling of Last Pass in my browser (IE) was what solved this problem for me, but along the way I learned a lot of other things that could have just as easily been the cause. A variety of other valid answers to this question (Some in the various answers on this page) are validated and explained here:
http://blogs.msdn.com/b/visualstudioalm/archive/2015/03/03/make-debugging-faster-with-visual-studio.aspx
This article explained that this F10 slowdown can be from having various diagnostic windows and toolbars open, Symbol loading issues, etc. and also explained what to do about debug slowdowns in general. It was an eye opening education that I think will continue to help me in the future should the F10 slowdown rear it's head again.
In my case it was the Call Stack window (Visual Studio 15.9.13) that caused the lag!
Even when I stepped over a very simple line like ++i; it took around 1-2 seconds until the debugger stepped over to the next line. Closing the Call Stack window or hiding it fixed the lag for me immediately.