(Note: not off topic per Is it appropriate to post vim questions on Stack Overflow now that there is a vi/vim site?)
On my mac using vim version:
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jun 10 2016 10:50:34) MacOS X (unix) version Included patches: 1-1219
when I am in visual mode, select a block of text, then click x, the text is removed but the whitespace remains. Here is a video: https://vimeo.com/176318393
similarly, when I paste using "+p (pastes from the system clipboard), the text overwrites whatever is on those lines and does not "bump" down the text being pasted. Video: https://vimeo.com/176319290
I want to solve these two problems but I have a hunch they are related so I am posting them in one question here.
A subset of my vimrc (vimrc is massive but nearly positive the plugin stuff has nothing that could affect this) that handles generic settings is here: http://pastebin.com/2APD1ycp
What is wrong?
The behavior shown in both videos is perfectly normal and expected in visual block mode.
You have visual mode and visual line mode at your disposal so, if you don't want the behavior of visual block mode… don't use it.
I downloaded DotSoft's DoByLayer tool for AutoCAD and ran the NETLOAD command as instructed on my AutoCAD 2016 product, but for some reason there is no ORDERBYLAYER command like there should be.
Does anyone maybe have any idea why it's not working?
Ensure you have do the following steps:
Unzip on a local folder (network folders are not supported by default)
Right click on the DLL, go to Properties and click on "Unblock" (if this option is not there, ok, no need to unblock it)
NETLOAD the proper version, I tried OrderByLayer19.dll (for AutoCAD 2016). Is there any error/success message?
AutoCAD 2016 is not supported. The more recent version is for AutoCAD 2014 (OrderByLayer19.dll)
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.
I had downloaded and installed VS 2010 Ultimate evaluation for 30 days. It allows me to get a 60-day extension if I register. My register just ended.
2 days ago, I got the extension key by registering but did not enter it because I thought I should wait till the product evaluation period expires.
Now, when I open up VS 2010, it gives me a dialog box with only two buttons:
a) Learn more about upgrading. This takes me to the same page that allows me either to buy or generate an extension key.
b) Close. This closes VS 2010.
How do I enter in the extension key now?
In order to update the product key you need to be logged on with administrator privileges. Try logging on as an admin and the go to the control panel > uninstall/change a program > Enter the product key > click "upgrade."
Here is a link from MSDN on how to do it for VS 2008 trial editions. It is the same for VS 2010:
http://msdn.microsoft.com/en-us/library/cc442563(v=vs.90).aspx
I did the same exact thing and it looks like the only option I could find after tons of googling is redownloading and installing the latest version to use your new key with. Here is the page I found with links to the downloads:
http://msdn.microsoft.com/en-us/vstudio/bb984878.aspx
NOTE: I have not yet downloaded this and tried the key I received from the 60 day extension but will let you know if this works when I get a chance to DL it in the next couple days unless anyone else can confirm.
(Probably too late, but here's an idea that may help someone...)
Try setting your computer's date back to a point in time when your trial was valid (e.g. 1 month ago). I've just tried this on an expired 2010RC and it ran happily, allowing access to the Help>Register menu option.
Of course, attempting to register in this way may detect that you're running "in the past" and refuse (at which point, try setting the clock back and see if it'll let you retry) - but it's worth a try before going through the pain of reinstalling the whole thing from scratch.
Try "Help -> Register Product". It can be your answer
I've installed Visual Studio 15.9.0, Preview 3 and created a project using the new platform support for C++/winrt. The project runs fine until I set a breakpoint. When the break is hit VS tells me "You need to find debuggerutils.h to view the source for the current call stack frame" It tells me this file was originally at onecore\com\combase\inc\debuggerutils.h, though it doesn't tell me the path to onecore. Search can't find such a file. Does anyone know how to find that file or install it? I had just assumed that VS would automatically include debugging capability.
[Update] Appears it is not the setting of a breakpoint but a bug causing a break before that. But I'm still mystified by the error message.
Someone asked this question on github's WinObjC issues:
https://github.com/microsoft/WinObjC/issues/2931
From the discussion:
edvv commented on Nov 22, 2019
Ah, now I remember what this means: "This is a false message. What really happened is that your app silently terminated (maybe by a console abort(), i.e.: crashed ) and when the app failed to launch (aborted) the front end gave that message. You need to look at the Windows Console window in VS while in debug mode."