ViEmu Blog

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!

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 http://twitter.com/jonbho). 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:

http://www.viemu.com/forums/viewtopic.php?pid=2456#p2456

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 (www.colemak.com), whose Vim mode for Colemak includes that mapping.

/ Tom]]

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:

http://blog.ngedit.com/2009/06/02/started-working-on-viemu-and-codekana-for-vs2010/

http://blog.ngedit.com/2009/06/15/first-baby-steps-of-viemu-in-visual-studio-2010/

And I’m tweeting regularly every step of the progress, asking for questions, etc… you can follow all the gory details at http://twitter.com/jonbho.

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!

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:

http://www.viemu.com/Install-ViEmuVS-2.2.9.exe

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.

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!

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:

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

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

It seems Microsoft changed something between their last preview releases and the final, RTM build of SQL Server 2008, and this broke ViEmu/SQL 2008. Technically, I was QueryInterface’ing the provided application object pointer for a DTE interface, which works for SQL Server 2005 and the preview builds of SQL Server 2008, but didn’t work (returned null) for the final build of SQL Server 2008 Management Studio. I found an alternate method to get to the DTE object: the AddInInstance object has a get_DTE() method which returns the sought-after DTE object. I changed this, checked it to work on both SQL Server 2008 and SQL Server 2005, and built 2.2.7 fixing this. Here is the link to download it:

http://www.viemu.com/ViEmuSQL-2.2.7.msi

This will automatically upgrade your existing installation if there is one.

Happy ViEmu’ing!

[I sent this email out last week to all current ViEmu and Codekana users, announcing the latest releases and outlining my plans for the near future. If you didn’t receive it but would like to receive future ones (they are few and far between), drop me a line. — Jon]

Hello everyone,

It’s a long time I hadn’t sent out an email to all ViEmu and Codekana customers. Finally, new versions of all the ViEmus are ready, and I thought this would warrant an email. The new versions are 2.2 for Visual Studio, 2.2 for SQL Server too, and 1.5 for Word&Outlook, and you can download them straight from the web site front page
(http://www.viemu.com), or from the links below:

ViEmu/Visual Studio — http://www.viemu.com/ViEmuVS-2.2.6.msi
ViEmu/SQL Server — http://www.viemu.com/ViEmuSQL-2.2.6.msi
ViEmu/Word&Outlook — http://www.viemu.com/ViEmuWO-1.5.1.msi

You don’t need to uninstall your current version before installing these ones, they will automatically upgrade any previous installation. By the way, I’ve revamped the build system, and now even minor revisions (of the form 2.2.x) include automatic upgrading. No more manual uninstalling necessary for any revision.

These builds have been tested over the last few weeks by hundreds of people now (it’s been the official download from the home page for over two weeks), so they are very reliable and should not cause any trouble. Just drop me a line if anything acts up.

The major new features are i’/a’/i”/a” text-object motions that allow you to operate on strings, gt/gT to navigate tabs, gp/gP for variations on regular pasting, and several more minor points. Also very important, these versions consolidate all fixes and improvements from 2.1.0 to 2.1.27 revisions in the VS/SQL line, and 1.0.1 to 1.0.25 revisions in the Word&Outlook line. You can check all changes in the release notes:

ViEmu/VS 2.2 — http://www.viemu.com/viemu-vs-22-release-notes.html
ViEmu/SQL 2.2 — http://www.viemu.com/viemu-sql-22-release-notes.html
ViEmu/W&O 1.5 — http://www.viemu.com/viemu-wo-15-release-notes.html

In the past few months, I have set up two new blogs, one ViEmu-specific and the other one Codekana-specific, where I post about every little improvement and minor revision. If you are a regular ViEmu and/or Codekana user, you can subscribe in order to stay informed of the latest news on each product:

http://www.viemu.com/blog/
http://www.codekana.com/blog/

This is nicer than sending out emails for every little change, and still allows me to communicate improvements efficiently to those interested.

I thought I’d also detail my plans for the near- to mid-term future, so that you know what ViEmu and Codekana are up to.

First thing, I will be concentrating in Codekana development for some time. I’d like to implement some new features, improve the website, and release a new 1.5 version of this product, which I want to turn into an
indispensable tool for serious development with Visual Studio in the mid-term. There’s a lot of work ahead, but there are many exciting features that are waiting in the roster.

After this is ready, I plan to work in ViEmu versions 2.5 for VS and SQL Server, and 2.0 for Word&Outlook. These versions will implement a new licensing system, mainly due to pirate key-generators being widely available out there, and installing them will require you to log in to a new customer area and download a new license key. I want to provide a nice line-up of features that will make the upgrade well worth the hassle of downloading the key. Codekana will also see some similar treatment.

Finally, ViEmu 3 is the next goal, for which there are many very useful and interesting features planned. The major new feature I want to provide is scriptability. Even in the vi/vim editing world, there are many small variations on how different people want their vi to behave, and often it just doesn’t make sense for me to implement every little variant. A scripting system will allow customization to your own taste, and allow everyone to improve it. I plan to offer some way for people to share scripts and that will also make it a much more valuable tool. The scripting language will be a javascript-like little language. I considered other options too: VS’s internal scripting, which I don’t want to use as it wouldn’t work in SQL Server, Word and Outlook, and other possible hosts; vim’s viml scripting language, which is very complex and I really dislike; and Python, which would be nice, but would make me use the Python interpreter — this would add complexity I don’t want to have in a tightly-controlled C++ codebase.

It’s also my plan to make ViEmu 3 the first version to carry a small upgrade fee for those who bought over a year before its release. This won’t be more than a small fraction of the full license price, and I want this version to provide plenty of value so that it will justify the extra fee. If not interested in the new features, you will of course be able to keep on using ViEmu 2 for as long as you want.

I’ve also been slowly advancing in the research of the technology that will power my yet-to-be-released, stand-alone text editor, Kodumi, and which will also see its way into Codekana and possibly ViEmu. This is a mid- to long-term effort, involving a completely new programming language and VM, but I hope the results will really pay off in the end. I’ll keep you updated when there are any news.

All in all, there are a lot of exciting improvements ahead, and I hope that you will find ViEmu and Codekana more and more useful in your day-to-day work as I can implement more and better features.

As always, I will be glad to hear any feedback, suggestions, bug-reports, or your thoughts about anything else. Feel free to drop me a line.

Thanks and best regards,

Jon
NGEDIT Software

[This was posted in August, but it was in the wrong location. I’ve just moved it over here to the right place. Apologies if it shows up anew on your feed reader. – Jon, December 1st ’08]

Just fixed a couple minor glitches with the respective installers, and added one check to ViEmu/VS’s runtime (to avoid certain race condition that has actually never happened, but who knows, may happen some day – I discovered this in the code shared with Codekana):

http://www.viemu.com/ViEmuVS-2.2.6.msi
http://www.viemu.com/ViEmuSQL-2.2.6.msi

They’ll automatically upgrade your current install if there is one.