VsVim

Free

VIM emulation layer for Visual Studio

(175) Review
Visual Studio
2013, 2012, 2010, 14
Download (196,449)
7/21/2014
1.7.0.0
View
E-mail Twitter del.icio.us Digg Facebook
Add to favorites
Description
Reviews (175)
Q and A (202)
Sign in to write a review
Sort by:

by case23_69 | August 08 2014

Awesome - thanks for sharing!!

by byte1918 | July 22 2014

It's the first extension I install in Visual Studio. It's a must have if you ever liked working with VIM. Thank you Jared. Awesome!

by Nathan Friend | July 08 2014

Very impressive extension.

by Matthew199 | July 03 2014

Simply fantastic, how have I gone so long not knowing this even existed! Thank you so much...

by Vinod Pankajakshan | June 27 2014

Vimming in Visual studio is simply mind boggling.. thank you for making this happen Jared Parsons.

by Porges | June 19 2014

by feverforce | June 12 2014

Awesome tool! Can't use VS without it.

by Iain Ballard | June 09 2014

One of the best Visual Studio extensions available. Along with R#, it's one of those "Wouldn't use Visual Studio without it" add-ons.

by Galen Elias | May 24 2014

This is extremely well done, I can hardly tell I'm not in Vim. Would be nice to have a bit more configurability, but overall this is great!

by Joe Egan | May 20 2014

This is always the first Visual Studio extension I install - could not imagine working in Visual Studio without it. VsVim is rock-solid and simply allows me to edit code more quickly.

For the uninitiated (or the Vi-traumatized):

1) It does not take comprehensive knowledge of Vi(m) commands to be much more productive with this extension (or Vi(m) generally). Basic Vi commands (http://www.cs.colostate.edu/helpdocs/vi.html) pack a lot of punch.
2) Yes, I am quite familiar with comparable Windows keyboard shortcuts for many things I do Vi-style using VsVim - and find myself seamlessly interleaving them with Vi(m) commands; TMTOWDI; but Vi is everywhere (including Visual Studio thanks to this awesome extension) and reduces reaches for my mouse and contortion on my keyboard more than anything else I have tried over 20+ years of nerdery.

Highly recommended!

by HoangITK | May 16 2014

I love it!

by Z Sun | May 13 2014

Very cool plugin, definitely made Vim users more productive in Visual Studio.

by Matt Winegar | May 07 2014

Sure, maybe I am using the wrong name for the feature (its really just renaming, not refactoring). In VS, if you highlight (select) a variable name, on the declaration, and type over it with a new name, an icon appears that you can click on to open a menu that says "Rename <old name> to <new name>". Then if you click that, VS updates all of the references to this variable to the new name.

Also, you mentioned C#, which I haven't tried this in. I noticed this in VB, which is what most of the code I am working with is written in. This is not resharper or a similar plugin, as I do not have these for VS 2013 (still vanilla on that).

I don't have to do the renames that often, so I can work around for now by temporarily disabling the plugin and re-enabling when done, with VS restarts. I wouldn't do this for small local variables, but for properties, etc. of classes that are referenced multiple places, this might still be the quickest way, as a workaround.

JaredPar MSFT May 07 2014
| Edit |
Delete

Ah, I didn't think about trying that in VB. I've played around with it a bit and I have a theory about why the rename refactor doesn't get hooked up after a select + edit. Going to look into this

by Thumbmunkey | May 07 2014

by Mateusz Stepniak | May 02 2014

Let the Vim force be with you
- in Visual Studio too!

by Martin Rykfors | April 23 2014

I really enjoy using this plugin and the author is doing a superb job maintaining it and responding to bug reports. A great opportunity to learn Vim!

by bumblebeeman | April 22 2014

by ovalsquare | April 11 2014

Indispensable.

by Pål Fossmo | April 10 2014

by mwbrady68 | April 05 2014

1 - 20 of 175 Items   
Sign in to start a discussion


  • Semantics of 'p' different to standard clipboard Paste behaviour.
    3 Posts | Last post Tue 12:37 AM
    • Hi Jared,
      
      This may be a Vim quirk, but it has been confusing me for a while. With standard text editor Copy/Cut/Paste commands, the action of pasting does not alter the clipboard contents which allows you to paste the same thing repeatedly. Suppose you have:
      
      GoodWord
      BadWordX
      BadWordY
      
      With standard commands, I can double-click on GoodWord to highlight it, hit Ctrl+C, then double click on BadWordX to highlight and hit Ctrl+V to paste and overwrite it with the word GoodWord. If I double-click BadWordY to highlight it again, with standard commands a paste will insert "GoodWord" as expected, but with VsVim's put command the text inserted is BadWordX (which was just overwritten in the last action), not GoodWord.
      
      It seems like the put command, when executed while Visual mode is active (i.e when something has been selected in the editor), will do a swap: the contents of the clipboard enter the selected area, and the contents of the selected area go into the clipboard. Invoking put when there's no selection will correctly insert the clipboard contents and leave the clipboard unaltered (so you can repeat it several times to paste the same text over and over again).
      
      gVim exhibits the same behaviour so VsVim is doing the "right thing" Vim-wise, but would it be possible to get a switch that turns on the Windows Paste semantics?
      
      Many thanks as always for your superhuman efforts maintaining VsVim!
      
      Eric.
    • Can you post your _vimrc somewhere I can take a look?  I'm pretty sure you can get this behavior with a combination of settings that are supported by VsVim.  
    • Sure: I sent you an attachment via email with the subject "Making 'p' in Visual Mode behave like Windows Paste."
      
      While researching how I may do this I came across the handy '[ and '] commands that move the caret to the start/end respectively of the text just pasted. Hope those will make it into VsVim sometime (apologies for bundling it here with another request).
  • Strange behavior in .cshtml
    10 Posts | Last post Thu 4:25 PM
    • Latest vsVim in VS2013.
      I have this line in a .cshtml file:
         @Html.ActionLink("CM Demo", "Index", "CM", null, new { @class = "navbar-brand" })
      
      Editor is in normal mode.
      If the cursor is in one of the quoted strings ("CM", for example).
      When I use this command:
      :wa
      I end up with this, editor is in insert mode:
         @Html.ActionLink("CM Demo", "Index", "C" +
                                               "M", null, new { @class = "navbar-brand" })
      
      Strange.
    • This should be fixed in the next version which is coming out on Monday. 
    • Problem still exists, VS2013, VsVim 1.4.2.0, ReSharper 8.0.2.
      
      Date.cshtml:
      @model DateTime
      @Html.TextBox("", Model.ToString("MM/dd/yyyy")) 
      ** TODO Wire up the date picker! **
      
      If the cursor is in the quoted string (in the "dd", for example), :w results in:
      @model DateTime
      @Html.TextBox("", Model.ToString("MM/d" +
                                       "d/yyyy")) 
      ** TODO Wire up the date picker! **
      
    • Hmm, it looks like my fix is only working a portion of the time.  There is a subtle startup race condition.  Looking into a more thorough fix 
    • Has this issue been addressed?  I'm still having it with VsVim 1.6.0.3, VS 2013 Update 2 and Resharper 8.2.1
    • I should also add, I LOVE VSVIM!  Thank you so much for it.
    • This ended up revealing a bug in Visual Studio that was fixed in 2013 Update 3.  Fully fixing this issue may require some work on my end even after the update though.  Hoping to get it installed and tested out sometime in the next few days 
    • Thanks for the update.
    • Even after updating VS2013 to update 3, insert behavior persist.
      Can u tell me when this would b fixed?
    • This bug is tracking all of the remaining work for :w in CSHTML files (post Update 3).  
      
      https://github.com/jaredpar/VsVim/issues/1349
  • creenMovement("j") inserted into document
    3 Posts | Last post August 12, 2014
    • I've just installed my machine clean, installed Visual Studio 2013 and then installed the latest VsVim 1.7.0.0.  I accepted all the default options and key bindings.  After I restarted VS I found that whenever I hit any of the Vim movement commands I'm getting the following printed in my actual code.
      
      creenMovement("j")
      creenMovement("k")
      
      ... etc
      
      Is this a bug or have I broken my config somehow?
    • Apologies, ignore.  The issue was being caused by the fact that my GVIM _vimrc file was being detected by VsVim and was causing problems.
    • Glad you were able to get that fixed!
  • ; and , for Till
    4 Posts | Last post August 09, 2014
    • Hello,
      
      it doesn't appear that the ; or , keys work with till (t).  Shouldn't be advancing the cursor to the next occurrence?
      
      Regards,
      
      -TJP
    • I just checked and this was working for me.  I put the caret at the start of a line, ran t; and the caret moved to the space before the ;.  What behavior are you seeing?
    • Sorry, I didn't quite communicate clearly.
      
      What I mean to say is that when I have a line such as
      
      font = g.Content.Load<SpriteFont>("hud");
      ^
      
      where ^ is where the caret is, and I press 'te'  (no quotation marks)
      the line will become
      
      font = g.Content.Load<SpriteFont>("hud");
                  ^
      
      Now, if I press the ';' key (no quotes), I expect the caret will advance to the next e location. ie
      
      font = g.Content.Load<SpriteFont>("hud");
                                 ^
      
      However, when I do this , the carret does not advance.
         
      
    • Thanks for the detailed steps!
      
      That behavior appears to match the behavior of gVim (verified on 7.2).  The `;` repeat search motion will exactly execute the previous char search.  In this case it is 'te' and the next 'e' is the one in front of the caret hence the caret doesn't move.  
      
      If you use 'fe' instead of 'te' then ';' will jump the caret forward (although it will be on the char instead of before it).  
      
      
  • Wish list: more autocmd support
    1 Posts | Last post August 08, 2014
    • Specifically:
          au FocusLost,TabLeave * call feedkeys("\<C-\>\<C-n>")
      
      Thanks for maintaining VsVim, I would not enjoy editing without it...
      
  • BUG: Unwanted scrolling in split window upon Undo command
    7 Posts | Last post July 31, 2014
    • Hi Jared,
      
      I have a source file open with a horizontal window split so I can see code in two different parts of the file simultaneously. Most editing seems to work OK, but when you are editing in the top pane, the Undo command seems to make the bottom pane scroll from whatever position it was in up to lines affected by the Undo action. Executing the Undo command in the bottom pane does not cause the top pane to change its scroll position.
      
      Hope I have explained that properly...seems like a bug (but I can't confirm in gVim because I don't know how to split the editor horizontally there).
      
      Many thanks in advance for looking into it,
      Eric.
      
      PS: I am now enjoying a higher quality of life thanks to the recently added 'ge' command :-)
    • I tried reproing this but was unable to do so.  What I did was create a new text file and pasted a whole bunch of text into it.  Then I split the screen and scrolled the top pane to the top of the file and the bottom pane to the bottom of the file.  After that I put the caret in the top pane, made some edits, ran undo and the bottom pane stayed scrolled to where it was.  Tried a couple of variations on this and couldn't get the bottom pane to scroll.  Can you see a difference in how we are trying to repro this?
      
      To split in gVim just use the command `:split` 
      
      Glad you are enjoying `ge` ;) 
    • I did what you did and couldn't repro either. Then tried it this way:
      
      1) open a file then make some edits.
      
      2) split the window horizontally, then scroll the bottom pane so it shows parts of the file not visible in the top pane.
      
      3) click into the top pane then invoke Undo. The bottom pane will scroll.
      
      4) from this point on, for any edit you make anywhere in the top pane, when you hit Undo the bottom pane will scroll to the location affected by Undo in the top pane.
      
      The trick seems to be making some edits BEFORE splitting the window. If you open the file, split the window THEN edit, it doesn't happen. 
      
      Let me know if you can repro it that way.
      
      Thanks again!
    • I tried that and still wasn't able to repro.  
      
      What version of Visual Studio are you using? There was a bug in at least 2010, and possibly 2012, which would lead to this behavior.  
    • I am using VS 2012 Ultimate Version 11.0.61030.00 Update 4, running on Windows 8.1 Pro 64-bit.
      
      I have also confirmed that the issue is probably VsVim related: when I disable the plugin and follow the repro steps I wrote the second time round, nothing happens. When I enable the plugin and follow the steps, the unwanted scrolling behaviour returns. The problem happens whether you have an existing file or use a newly created one, whether you are in a solution or editing the file "stand-alone".
      
      Hope that helps you hunt it down, though the bug is not too important (I do split window editing maybe once every several months).
      
      Thanks as always!
    • Thanks for the info! I was able to repro it on 2012.  It looks like it's the undo bug that I mentioned earlier and it appears to be fixed in 2013.  Unfortunately it's not really fixable in 2012 without breaking other behavior.  So I may just let this one go since it is fixed in later versions of VS.  
    • Many thanks, will be upgrading to 2013 soon, so no worries there!
  • Display Register Contents
    5 Posts | Last post July 25, 2014
    • Dear Mr. Parsons,
      
      I have found your VsVim extension to be very useful, and I am very grateful that you are developing it.
      
      Would you mind implementing the :reg (:register) command into VsVim so that a user can see the contents of the registers?
      
      Best Regards,
      
      -TP
    • Glad you're enjoying the extension!
      
      The :reg command is implemented but only the version that doesn't take any arguments.  So if you type :reg only it will show everything.  I have the following bug filed to add support for specifying individual registers
      
      https://github.com/jaredpar/VsVim/issues/1379
    • Dear Mr. Parsons,
      
      Excuse my ignorance, but where does the output of the :reg command show up?
      
      I don't see any sort of VsVim output window or something like that.
      
      Best Regards,
      
      -TP
    • It will appear is the same place where you type out the commands.  That window is dual purpose for editting commands and displaying output.  
    • Dear Mr. Parsons,
      
      Thank you for your help. I now see register contents listed.  
      
      It's strange because I thought I had done this before and I saw no output.
      
      I'm unable to recreate the error. (albeit I'm new to VIM).
      
      I'm curious if all the registers were to be cleared if any output would show.  Perhaps if there were no registers filled, there would be no output.
      
      Best Regards,
      
      -TJP
  • Ability to pass current filename to external command
    2 Posts | Last post July 24, 2014
    • It would be great if one could pass current filename to external command.
      
      Vim uses % symbol for it. So for example to open current file in notepad I would do:
      !notepad %
      
      I could run some svn commands to see the history of a file, blame and so on.
    • Thanks for reporting that.  Here is the bug that is tracking getting that feature into VsVim
      
      https://github.com/jaredpar/VsVim/issues/1038
  • DD command cursor
    3 Posts | Last post July 23, 2014
    • Hi Jared, when you first type the d command the cursor in normal mode should go from a full block to a half block letting you know you pressed the key for the first part of a command, this currently works on the y and c commands perfectly and I thought before the upgrade this used to work. I'm using version 1.7.0.0.
      
      Is there a hidden setting that makes this work like it used to?
      
      Thanks.
    • I just checked and VsVim will use the half block on `d`.  If it remains in a full block that typically means you have a normal mode mapping involving the `d` character (say :nmap da blah).  In that case when you press `d` there is an ambiguity and VsVim correctly keeps it at full block
      
      Eventually though the key mapping should time out in favor of the delete version of `d`.  At that point VsVim should be redrawing the caret at half block.  It is not though.  I filed the following bug to fix that up 
      
      https://github.com/jaredpar/VsVim/issues/1409
    • You are correct, I had a d mapping, I removed it and it works like normal again, 
      
      Thanks for your hard work on this.
  • ge command not working
    3 Posts | Last post July 18, 2014
    • Hi Jared,
      
      In gVim I can type 'ge' in normal mode to jump to the last character of the previous word, but for quite sometime now I can't get this to work in VsVim (using v1.6.0.3 with VS2012 Update 4). 
      
      Is this feature supported?
      
      Many thanks,
      Eric.
    • Great timing on the question. I just added support for 'ge' into the code base 2 days ago.
      
      https://github.com/jaredpar/VsVim/issues/1124
      
      If you want to grab a build that has this feature you can do so from here 
      
      https://ci.appveyor.com/project/jaredpar/vsvim/build/artifacts
    • I still can't believe this thing is free! Many many thanks Jared!
1 - 10 of 202 Items