You can take the developer out of Linux, but you can't take the Linux out of the developer. This extension makes my coding time so much less frustrating. It has some gotchas, but the power and ease it gives are well worth it (hence the 5 stars).
I've got a full review here: http://www.readytorocksd.com/vsvim-review-30-days-with-visual-studio-extension-vsvim/
Hi I'm using VS2010 SP1 and tag blocks don't seem to work for me. Any *it command doesn't seem to apply. Is there a setting I'm supposed to enable or something I'm supposed to write into my vimrc file?
I've been using your extension for a while in both visual studio and atmel studio with great success. Thanks for putting this tool out there!
Recently Atmel Studio has been updated to version 6.2.1563 and vsvim no longer shows up in the extension manager search.
Is there any way to install vsvim manually? Do you plan on supporting Atmel Studio?
Without this plugin my productivity has diminished at least 43%.
I didn't realize it had stopped working for Atmel Studio. I will look at getting that fixed.
In the meantime though the latest VsVim should work fine for Atmel. Try downloading it from here and double clicking on the file. It should self install into Atmel Studio.
When I run the VSIX Installer the only products that come up are
*Microsoft Visual Studio 2010 Shell - Integrated Mode
*Microsoft Visual Studio Professional - 2013
Unfortunately it does not find the Atmel Studio Installation.
The link I provided earlier is now updated with a version that should install into Atmel 6.2. I also updated the version of VsVim in the official Atmel Studio gallery. It usually takes them a few days to verify the new uploads but once that completes it should show up directly in the extension manager again.
I just installed VsVim into the new VS2015 RC Community.
After a restart the familiar vim interface failed to show up.
When I went to the setting there was a node for VsVim but it only shows an error saying the plugin could not be loaded.
Is something wrong with my setup or is this a general issue with this version of VS?
The `ib` and `aB` motions are implemented. But they are two of the lesser tested motions hence it's possible there is a bug here. Is there a particular scenario that isn't working that you could show me?
Nice job!. But is that possible to revert the back/forecolor when cursor blink under normal mode. It really hard to recognize the character under cursor. I try :set guicursor. Seems no that option in VsVim. I use VS2010
I follow ur methods tried, but did not play a role.It's useful in VS2013,but in 2015 does not work.Could u please try to sovle it?
By the way, do you know what the font is in this comment area? it is very good.
There is a bug in VS 2015 that prevents this from working. It should be fixed in the next public release.
It appears the font is monospace (at least that is what is showing up in Chrome developer tools).
A long and white status bar looks bad in VS2013 with dark theme, how can I change the background and text color of the status bar?
And, Visual Studio has its own status bar, why not just use the visual studio status bar instead of creating your own? I really want to save screen space as much as possible.
The color of the command margin can be changed in Tools -> Options -> VsVim under the Item Colors section. Both the foreground and background can be changed here.
The Visual Studio command bar just really isn't sufficient for the needs of Vim. At a high level it's meant for short term, non-editable, global status messages. Vim needs long term, editable, local command bar. There are other more technical reasons why I made this choice but at a high level that's the reason.
I have gotten enough requests for this though that VsVim does support using the status bar only. To enable that go to Tools -> Options -> VsVim and set "Use Editor Command Margin" to false.
Note: This is a brand new feature that I don't actively use myself. It probably still has several bugs that need to be ironed out. And long term it won't be as functional as the command margin (in particular it won't support edit). But overall it should serve as a reasonable substitute.
Thanks for the reply, I'm new to vim so I didn't really know what command margin means when I asked that question, sorry to bother you for that
But there is a minor problem that I hope you can help me solve:
I am a chinese, and like all other programmers in China or Japan and some other countries, we use input methods to input our language.
In insert mode, there is no problem.
In Normal mode, when I type 'i' for example, I meant to enter Insert mode, but if my input method is active, the input method will intercept my input, so I have to disable my input method and type again, this is a bit annoying.
Is there anything you can do from your end to disable input method (if enabled) temporarily when in Normal mode?
Sorry, make mistake.
This link is correct.
1. open Vs2013 and enable vsvim(Handle all with VisualStudio).
2. switch input from english to chinese. then vsvim will not work normal.
For example, Ctrl + j to list members, but in this situation, it will linefeed.
I've been debating making the jump from ViEmu to VsVim for better config support via vimrc (currently the only usable mapping that makes sense is 'nnoremap <esc> :noh<cr><esc>'), but I'm struggling with navigating between window splits. I've figured out splitting via command mode with :split and :vsplit but normal mode commands <C-w> s, <C-w> v, and <C-w> w do not work. I haven't found a way to move between horizontal splits without using the mouse, and I can't navigate between vertical splits at all without using <C-tab>.
Using ViEmu, I'm used to gt and gT taking me to the next buffer, regardless of tab well, though I appreciate the difference in VsVim where every open tab is treated as an open buffer, there's no indexed buffer list (:ls) so I can't jump to a given buffer (:b1 :b2 etc) without cycling through every open tab. I'm also unable to open a new buffer (:e SomeFile.cs) which keeps me reliant on the solution explorer search.
I feel like I'm missing something fairly major, but I've searched and all the ways of splitting and navigating splits and buffers doesn't seem to be supported outside of :split and :vsplit
As for the <Ctrl-W> commands I just wasn't aware of them. I've been using the :split and :vsplit commands for as long as I can remember and had never seen this alternative. It's fairly easy to implement and I filed the following issue to track getting the work done
As for the buffer list. Vim and Visual Studio unfortunately have a very different understanding of how buffers work. A couple of times I've tried to map out how the buffer commands should work in the world of Visual Studio but I've been unable to convince myself of a model that made a ton of sense. If you have any ideas here I'd love to hear them.
For :e the command is implemented today but has no sense of relative path. How are you expecting the path to be resolved here? Relative to the current project, solution, etc ...?
As far as a buffer list goes, it would be nice just to use :ls to get a numbered list of files that are open, you don't necessarily need to treat a vertical split of the same file as separate buffers. gt and gT would cycle numerically through the buffers forwards and backwards (alternate commands are :bn and :bp), as well as :b n to jump to buffer n. The ordering of that list is entirely up to implementation I suppose. Tab order is the initial thought, but multiple windows, screens, and tab wells complicate things. If VS has a way to progressively iterate through those by level (window, well, tab) that I guess would be the simplest way to go, since "order opened" doesn't make sense when opening a project with files already open. ViEmu only places a file in the list if you've made changes to it during that session or it was the first file with focus, but then you have to :e FileThatIsAlreadyOpen.cs to be able to jump to it. It's not the worst idea, I suppose.
for :e, I just tried using it and even from a file in the same folder I get "The document cannot be opened. It has been renamed, deleted or moved." I'm used to typing :e fileiwant.cs non-case sensitive regardless of path, sort of like a quick find, though I don't have many projects where the same file exists in multiple paths so I never thought about the particulars of path relevance. If one were to build in path relevance if path is specified, it should probably be from the solution root.