ViEmu Blog

I’ve just built & uploaded new version 2.2.8 of ViEmu for Visual Studio. Here is the link to download it, it will auto-upgrade any previous installation:

http://www.viemu.com/ViEmuVS-2.2.8.msi

It brings two minor fixes and a hopefully very useful improvement:

• It works better with LUA files when Visual Assist is present
• It fixes the behavior of the motion “100%”, and  makes “{n}%” behave exactly like vim
• And most importantly, it improves compatibility with Resharper. Read on if you use both ViEmu & R#!

The main complaint about ViEmu and Resharper interaction has always been what ViEmu does when using one of Resharper’s inline-mode features. When you issue a refactoring like “Rename” on a local variable, use one of the “Create class” / “Create method” / … refactorings, or when using a live template (type “for<tab>”), R# enters a special mode where you can edit the name of the highlighted element, while it changes all other instances too.

This is the problem: Resharper doesn’t know squat about ViEmu, insert and normal modes, and what have you. So ViEmu can stay in normal mode, while it should enter insert mode. Worse yet, since ViEmu auto-enters visual mode when it detects some external action has selected a range, it could enter visual mode, and ESC wouldn’t let you exit it (it would exit the inline mode).

Since as early as Resharper 1.x (around November 2005), I received reports of this from users of both Resharper and ViEmu, and added some provisions to ViEmu. The main way I did it was to detect and intercept the relevant R# commands (“Resharper.Rename”, etc…) and auto-enter insert mode. This was an acceptable fix sometimes, but it featured two shortcomings:

• I had to add new commands to this code with each new version of Resharper, especially as the JetBrains guys are keen on renaming the commands in every release (“ResharperAddIn2003.Rename”, “ResharperAddIn2005.Rename”, “ResharperAddIn25.Rename”, “Resharper.Resharper_Rename”, etc…). This always had me on the losing end of the arms-race with them!
• Some commands don’t use the VS mechanism (the red light bulb, etc…), so I couldn’t intercept them!
• And finally, I couldn’t detect the moment the special “R#-inline” mode was exit! This meant you’d have to press Return to accept the changes, and then Esc to exit insert mode.

Well, finally I have implemented a new method that, although less elegant design-wise, works much better. I had tried this a few months earlier but was unable to make it work, but I finally got it to work properly. What I did? Since Resharper highlights in a special color the identifier you are editing, and since it uses VS’s marker mechanism to highlight it, I can check continuously whether any part of the buffer is highlighted with that marker (this is allowed by VS’s extensibility API). When I detect this marker is present, I make ViEmu auto-enter insert mode. The first great nice thing is that this supports *all* commands that use this mode, in all versions of R#, and in *all* versions of Visual Studio. And the second great nice thing is that I can detect when the mode is exit (no more  marker), and return to normal mode.  Hurrah!

I’d be happy to hear about how the R# interactions work for you with the new system! I hope to make ViEmu<->Resharper interaction still better in the future.

And there have been a couple of nice blog rants about ViEmu lately, one by Kyle Baley about R# interaction and another one by Tomas Restrepo about the actually very confusing keybinding configuration dialog. I’m hoping I can find time next week to respond to both, and some more time shortly to fix the actual underlying issues.

Finally, just wanted to let you know that I’m now neck-deep in Twitter, you can reach me there as @jonbho. It’s great to be in touch with so many customers and people whose thoughts I value!

I’m actually going to do my first release announcement via Twitter in a moment 🙂

PS:  This is actually the same interim 2.2.7.R#2 version I posted on the forums (at the bottom of http://www.viemu.com/forums/viewtopic.php?id=485), re-tagged 2.2.8. It’s been tested for a few days.

When ViEmu/VS runs for the first time, it unbinds many keybindings from VS commands, so that they can be used for ViEmu in their vi/vim meaning: Ctrl-O to go back in position history rather than open a file, Ctrl-F to scroll down one pageful of text instead of bringing up the find dialog, etc…

There is one key which I leave bound to its usual meaning: Ctrl-V. In vim, this key starts the very useful block-visual mode, where you can select a rectangular region of text. In ViEmu, it can do this too, but since I thought removing the “Paste” binding of Ctrl-V could be too intrusive, it won’t work right out of the box after installing. Ctrl-Q is understood by ViEmu as an alternative, so you can always use that. Actually, I copied this behavior from gvim’s default keybindings on Windows.

I receive requests every so often from people who think that ViEmu doesn’t support block-visual mode, and it’s a bit sad to me. I’m considering adding Ctrl-V to the keys from which ViEmu removes keybindings upon installation. Of course, this could be confusing to other set of people: those who expect that Ctrl-V will keep pasting, and who will feel frustrated when they find it doesn’t.

So I thought, now that there are quite a few subscribers to the ViEmu blog, what better than to ask here to many actual users to see what they think?

Just to be totally clear, here is the question: do you think that ViEmu/VS should stay as is, leaving Ctrl-V bound to “Paste” upon install? Or do you think it should unbind its Paste meaning so that Ctrl-V will get ViEmu into block-visual mode right out of the box?

Thanks for your input!