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/
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,
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.
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.
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?
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
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.
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:
I could run some svn commands to see the history of a file, blame and so on.
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 188.8.131.52.
Is there a hidden setting that makes this work like it used to?
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
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 v184.108.40.206 with VS2012 Update 4).
Is this feature supported?
Great timing on the question. I just added support for 'ge' into the code base 2 days ago.
If you want to grab a build that has this feature you can do so from here
Consider the following text:
public SomeType MakeCopyFunc(SomeType 5)
If I place the cursor on the 'S' after public then type cwMyObjectType<esc> it will delete SomeType,and replace it with MyObjectType. This is good. But then I navigate to the 'S' after the '(', and hit the '.' key to repeat the last action, rather than replace SomeType with MyObject, it will replace it with _MyObjec .
Any idea what would cause this?
I can't quite figure out why it does it sometimes and not others. I will report back when I have it narrowed down.
That definitely shouldn't be happening. I have a lot of tests for this feature, many on very similar scenarios so I'm not sure why you are seeing that. If you are able to narrow this down please let me know
I don't know the vim well; however, I usually use the "shift+8" to find same keyword.
"N" is used to go next find result, and the "shift+N" is used to go previous result.Current version of VsVim is operated well for "shift+8" but there is no highlighting. Is it possible to highlight the keyword of the result of the "shift+8" ?
Right now you can do this by just using a Windows Paste operation (Ctrl+V). I have the following issue tracking getting Ctrl-R support into the command line editor
I downloaded the version from this site but the issue described here (https://github.com/jaredpar/VsVim/issues/1088) is causing me problems. Is it possible that a regression has been introduced since this bug was fixed?
No, there is no real equivalent for that in VsVim.
However that does look like a super interesting idea. I'm toying with the idea of just writing a stand alone EasyMotion plugin for Visual Studio. May try and do that later this afternoon as a fun project. Will post back here if I do.
Yeah, EasyMotion is incredible useful for navigating inside the current visible part of code. I can't live without it in gVim :)
If you have the time to code it a few things would be nice to have:
- Beeing able to set the keyboard shortcut for it (e.g. Ctrl+,)
- It would be nice if we can define the character range
By default it's normally "a-zA-Z0-9"
but I normally exclude 0-9 to make the keys easier to reach.
Thanks Jared for considering it!
I started working on it today and have the basic mechanics working at this point
Still needs a *ton* of polish, in particular getting the initial search bound to a key stroke rather than a menu item. Will probably get this posted by EOW unless I hit some kind of snag
Added a very early version of EasyMotion to the gallery. Still very much alpha / beta but can be played around with. Please let me know about any issues you find (probably quite a few)
Github (code + issues): https://github.com/jaredpar/EasyMotion
Thanks for reporting the issue!
Right now this feature isn't supported. Only :reg without options is actually implemented. The reason you are seeing the different behavior for :reg " is that the parser is interpreting " as a comment and hence just parsing out :reg by itself.
I filed the following issue to look into this