ViEmu Blog

A blog about all things ViEmu
the one true editor
since 2005!

ViEmu for Visual Studio 2010 Beta 1 ready

May 18th, 2010

So, finally, here it is. It’s a bit rough on the edges but it should be usable:

Download it, double-click on the file, and you should be good to go. It will show up in the next session of Visual Studio. It will offer to reassign keybindings to ViEmu, if you want to restore them afterwards, you will need to use VS’s “Reset Settings

Known issues:

  • No hlsearch (yet)
  • No folding/wordwrap support
  • Coexistence with Visual Assist is so-so
  • No Settings dialog available
  • Documentation isn’t updated
  • Ambiguous multiple-key mapping processing doesn’t automatically time out

These other features will be implemented in a few weeks (our estimation of how long it will take). There are no known actual show-stoppers, if there are any, let us know and we will try to fix it ASAP to allow you to use it.

They used to say that the good thing of moving from VHS to DVDs allowed you to buy all your movie collection all over again. The good thing about re-implementing ViEmu in the new VS architecture, using managed code and .NET instead of native code and COM is that we get to re-implement all features again and re-fix all problems with other 3rd party editions.

This beta uses the new license-key system, you can go to and use the password-recovery mechanism to get your new-style license key (use the email address you used for your purchase ). The beta will work all licenses bought during the last year, and it will work in trial mode for 30 days in all other cases. If you buy ViEmu/VS now from the online store, the license you get will be valid for both ViEmu/VS “Classic”and for ViEmu/VS2010.

In a few days we will have the mechanism in place for customers who bought ViEmu/VS a year or more ago to buy the upgrade. This upgrade will also include one more year of full support and free upgrades, for both ViEmu/VS “Classic” and ViEmu/VS2010. The price will be US $29. We feel it will be great value for money at that pricepoint, and we hope upgrading won’t be too steep for anyone.

All feedback is welcome.

ViEmu 2.5 pre-release available: multiple-key-chord mappings and Ctrl-A/Ctrl-X

April 22nd, 2010

The new ViEmu 2.5, for all of VS, SQL Server and Word&Outlook, is ready for download:

(Symnum Systems is the new incorporated name of the old NGEDIT Software, be ready for a full phase-out of the old name everywhere.)

Before anything else: this version doesn’t support VS2010 yet, but we’re working on it, and I hope to have a beta available in 3-4 weeks. Watch out here for news, or follow me on Twitter. I know we’re somewhat late with this, moving from native C++ and COM to managed C++/CLI and .NET has been quite a challenge. The good news is that the new integration will allow awesome new functionality in future versions of ViEmu and Codekana. ViEmu/VS2010 will be free for those who bought ViEmu/VS less than a year before it, and it will carry a small support-period-extension fee for those who bought before that.

The main new features are multiple-key-chord mappings and Ctrl-A/Ctrl-X.

Multiple-key-chord mappings allow mapping a sequence of keys:

  :nmap c_ ct_

And when you type c_, ViEmu will process ct_. Of course, the most difficult  part is that when you type just ‘c’ ViEmu has to wait and see if what comes next is an underscore, or something else, and decide what to do. That is, ambiguity arises. And to be fully compatible with vim, this wait has to timeout configurably, etc… which ViEmu does.

I am not that much  of a user of these mappings, but some people have serious power configured in their .vimrc’s using this functionality, and they will now be able to bring it to ViEmu.

Ctrl-A/Ctrl-X on the other hand are in principle very simple commands: they increment/decrement the number where the cursor is. Actually, the implementation is a nightmare, as they work with decimal, octal, hexadecimal and on single alphabetic characters, and there are a lot of complex rules controlling how they work. I thought this would be simpler than the multiple-key-chord mappings feature, and it turned out to require much, much more work. In any case, there it is for you to enjoy in this new version. Let me know if some edge case is not handled correctly.

I’m doing a pre-release before the official release, because this release incorporates the new license-key system, and I want to roll things out slowly to test everything. The link above has all the information on how to obtain the new-style license key. If there is any problem, just get in touch with me via email or using any of the support forms.

New student and non-profit/educational pricing

November 22nd, 2009

I’ve just updated the store page announcing the new student pricing (50% off), and the new educational and non-profit organization pricing (25% off). The discounts were 20% and 10% before. Especially for students, and given the current general financial climate, I’ve come to think a price of $49 makes much more sense. Hope it will be well received!

I had already been giving this larger discount to students and non-profits for some time, so I doubt anybody feels unfairly treated with this change. If you do, be sure to get in touch and I’ll see how we can fix that.

NGEDIT blog post with info on the next ViEmu steps

September 24th, 2009

I just posted on the NGEDIT blog:

New Codekana web site, preview of the J1CK Twitter client, and next steps

It mainly talks about about the new Codekana web site and the J1CK Twitter mobile client, but it also includes some information on the next steps for ViEmu.

As a summary, the main next steps are the new Symnum/NGEDIT customer portal, a ViEmu 2.5 release with some new features, and ViEmu for VS2010 after this. I’m really eager to finish the infrastructure improvements I’ve been working on lately, and get back to providing new useful features for ViEmu!

A Vim and ViEmu mapping you *really* can’t miss - never type :noh again!

June 16th, 2009

Today, I noticed a mapping Tomas Lundell had posted on the ViEmu forums two months ago. Here it is in all its glory:

:nnoremap <esc> :noh<return><esc>

It’s the kind of mapping that, when you read and understand, it makes you think: “how can I not have thought of this before?”, and even, “how come this is not all over the net?”. I have added to both my _vimrc and my _viemurc, and I’m sure it will be with me for many years to come. The kind of mapping I’ll never forget. And this is from someone who <em>doesn’t</em> like to customize his editor(s) too much - my _viemurc is only5 lines, and my _vimrc is a meager 24.

What does it do? I will explain it in detail for those of you who don’t have all the background. If you don’t know what it does, then this post contains more than one valuable lesson for you.

Its function is related to vim’s “hlsearch” feature. When you search for a string in vim, either with / or ? (forward or backwards), or even with :g or :s, if hlsearch is set (”:set hlsearch”), vim will highlight all instances of the string. If the pattern was a regex, all sequences that match will be highlighted. This, as you can imagine, is very useful. It’s actually the “inspiration” (ahem) for one of the features of Codekana, which adds this functionality to Visual Studio’s native search. Bringing vim features to poor souls who depend on regular editors is a surefire way to improve their editing experience… But now on to the mapping.

Once you’ve seen all matches of the string, and you have done what you wanted to do, those highlights become an annoyance. And this is where the problem comes — the vim-standard way of removing the highlights is typing the “:nohlsearch” ex command. You can abbreviate it to “:noh”, but that’s about it. There is an alternate way: just search for a string that doesn’t appear - say, “/asdfgh”, which will remove the highlights. But this is ugly.

So the hlsearch feature is great, but it becomes an annoyance after using, and the annoyance is cumbersome to get rid of. Ouch.

Different people solve this in different ways. You can assign a keybinding to the :noh command. I tried to map it to “\”, which is unused by vi/vim’s keymappings, but couldn’t train myself to use it. Someone suggested “<alt-n>”, which is kind of nice because ‘n’ and ‘N’ are the vi motions for “find next” and “find previous”, but I just forgot to use it. I have always just kept using :noh every time. Until today.

The new mapping does magic. It maps the <Esc> key in normal mode to remove the highlighting (:noh<return>), and also to keep doing the typical function of <Esc> (by default, in normal mode, it will just beep). This is amazing. It’s reminding me of what Python programmers say about things being “pythonic” or not. This mapping is totally “vimmic” — it fits with the rest of vi/vim editing, it doesn’t remove any other functionality of vi/vim, it doesn’t even gobble up other keys which could be used as map-leaders (this is another advanced topic), and it is memorable and discoverable (I won’t forget it, because I will be reminded every time I pressEsc).

I tweeted about it (I’m very active inTwitter lately, and liking it a lot — I’m at Several people are already retweeting it, even if I didn’t add any explanation (I will now tweet a link to this). I hope this will become popular and reach every vim user, because it’s really good and useful.

It’s shameful that I didn’t really pay the original post the proper attention then, until another person commented on it yesterday. My apologies, Tomas! And one thousand thanks!

Although this forum thread hasn’t been very active, just this has made it worthwhile that I added the sticky topic for tricks at the forum:

And I hope this forum thread and the creativity of Vim and ViEmu users will generate more gold like this!

[[Update from Tomas Lundell: he wrote in with this comment:

Thanks for the kudos. However, much like everything else in the world, I didn’t come up with it. Any glory should go to Shai of Colemak (, whose Vim mode for Colemak includes that mapping.

/ Tom]]

Work underway in ViEmu for Visual Studio 2010

June 14th, 2009

I’m already working in ViEmu for VS2010. It’s a lot of work, because they’ve totally replaced the editor, but I’m confident I will be early for the VS2010 release. Also, I’m excited the new editor and extensibility model will allow me to offer an even better experience and cool new features.

I’m also working in Codekana for VS2010, but ViEmu comes first.

I’m posting more details at the NGEDIT blog:

And I’m tweeting regularly every step of the progress, asking for questions, etc… you can follow all the gory details at

By the way, I will of course keep supporting and improving ViEmu for the “older” Visual Studios indefinitely, and I do plan to implement improvements that will apply to both versions. The vi/vim emulation core is a shared codebase, so any emulation improvements go to all the ViEmus. Anyway, there will indeed be improvements that will be VS2010-only, given the possibilities the new architecture provides. I do think VS2010 will be a hit, much more so than previous VS versions, so most people will end up moving, but of course there’s always a lot of code that won’t be migrated, and we’ll be using older VS’s for years to come!

ViEmu/VS 2.2.9 ready - new installer and a couple fixes

May 25th, 2009

The fixes are quite minor:

  • The | motion with a count (go-to-column) was off by one compared to vim
  • Added :ern[ext] and :erp[revious] that map to VS’s View.NextError and View.PreviousError

But, apart from this, the main change is that the installer is based on an EXE file, which makes it work better with Vista and Windows 7 with UAC enabled. It will now ask for elevation when you start the installer. Here is a link to download it:

I won’t make the front page link to this new version until I’ve got some feedback, as I’m wary an EXE file may be more problematic than an MSI one.

I’ll be grateful for any feedback.

Next challenge: ViEmu for Visual Studio 2010. I’ve already started “playing around”.

.NET,  here I come.

ViEmu/VS 2.2.8 Released - Better Resharper support!

March 12th, 2009

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:

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, re-tagged 2.2.8. It’s been tested for a few days.

Request for comments: what should ViEmu/VS do with Ctrl-V upon installation?

March 3rd, 2009

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!

ViEmu/VS 2.2.7 for better Visual Assist interaction

January 31st, 2009

I’ve uploaded version 2.2.7 of ViEmu for Visual Studio. The changes in this build only affect interactions with Visual Assist X. For their latest builds, VAX has started intercepting HTML and several XML file types (pure XML, XAML, etc…), in order to provide some of their features there. ViEmu had some provisions from the time they didn’t act on these file types, and I have adapted this provisions to the new situations. It’s necessary to follow these things closely for the best interoperation between ViEmu and Visual Assist (for example, only let VAX pop-up their autocompletion boxes on insert mode, etc…).

It’s possible you will need to have a recent version of Visual Assist X for the new ViEmu to work with it properly. I’ve tested it with a few VAX builds and it works at least equally well for somewhat recent versions, and, for HTML/XML editing, the best is if you use VAX 1707 or later (VAX will enhance editing there).

This ViEmu (and future ones) may not work at all with old versions of VAX. I wouldn’t like to have ViEmu act differently with different VAX releases. For one, I don’t know how to get the build number, they don’t show it in Help|About which would be somewhat accessible. But mainly, having a version-number hack to decide which hacks to turn on and off starts to look too hackish and too much effort for the pay off.  Upgrading to the latest VAX version would fix it. This said, ifyou are stuck with an older version of VAX, you can write to me and try convincing me that I should invest the time to fix this.

Here’s the link to download it:

You needn’t uninstall the previous version, this will auto-upgrade your installation automatically.

I tested this on VS.NET 2003, VS 2005 and VS 2008, with and without VAX, it shouldn’t be problematic for anything else


ViEmu: vi/vim emulation for Visual Studio, Word, Outlook and SQL Server:
See where ViEmu customers are around the world:
Map of ViEmu customers around the world
Hear what others are saying about ViEmu:
ViEmu testimonials
Learn vi/vim easily with this cheat-sheet and tutorial:
Vi/vim Cheat Sheet and Tutorial
Read why vi/vim editing is the killerest:
Why vi/vim editing?
Discover ViEmu's sister product, Codekana:
Codekana outliner and syntax highlighter