ViEmu Blog

I’ve just fixed a problem in ViEmu/VS that happened when Visual Assist is installed under VS2008. ViEmu wouldn’t work properly in XAML files in this setup – you’d get the block cursor, but vi commands wouldn’t work – keys would just type normally, and Esc wouldn’t exit this pseudo-insert mode.

This has happened in the past with HTML and XML files under previous versions of Visual Studio. The reason is the following: ViEmu works by hooking editor windows (subclassing in Win32 terminology) and intercepting keypresses to do its thing. When Visual Assist is present, ViEmu has to intercept the window after Visual Assist. The reasons is that, if not, Visual Assist might process a ‘b’ keypress, assume it means you’re typing, and pop up an autocompletion dropdown with types starting with ‘b’ (bool, etc…). But actually, this ‘b’ was done in normal mode, and ViEmu will just move the cursor to the beginning of the previous word.

As you can easily see, ViEmu needs to process the ‘b’ keypress first, and it ensures it doesn’t proceed and isn’t processed by either Visual Assist or VS’s own system. For this to work fine, we have to get the keypress before Visual Assist.

Well, Visual Assist is notoriously unpredictable as to when it will hook the window itself. It does it at some point after loading the file, but it can be either immediately or a few seconds after loading it. It’s probably parsing or loading or doing whatever in the background.

Well, the Visual Assist devs were so kind as to provide a way by which you can check whether they have already subclassed the window. Having this, ViEmu was able to just query it and not hook the window until Visual Assist has. Of course, I need to detect whether Visual Assist is installed, because, if not, the check to see if they have subclassed it will make ViEmu wait forever.

The additional problem is that Visual Assist doesn’t hook *all* text editing windows. For example, it doesn’t act at all on HTML & XML windows. So, in the case of this file types, I have to identify them, and *not wait* for Visual Assist. The way I do this identification is by asking Visual Studio which language service is handling the window. If it’s XML, HTML, XMLA, etc… then I just don’t wait for Visual Assist hooking even if we have detected Visual Assist is installed.

You can see how this is getting pretty hairy.

Ok, the final drop that causes the problem is that Microsoft keeps adding new language services for XML, XAML, and similar formats in each version of Visual Studio. When they do this, the end result is that ViEmu gets stuck and non-functional in the new XML-variants. And I have to add a new langsvc to the list of exceptions and put out a new build of ViEmu/VS.

This is what I just did, ViEmu/VS version 2.1.17, which works just fine in the above combination. Hopefully I have covered all new such cases in VS2008 (XAML and XOML, and don’t ask me, I don’t know what XOML is, but it’s in the list of new language services in VS2008’s registry hive). Here is the link to download it:

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

Remember you have to manually uninstall the previous 2.1.x version before installing this one.

And, incidentally, this is the same reason of another problem that comes up every few months: if you have ViEmu and a Visual Assist X trial installed, and if the VAX trial expires, ViEmu will stop working. This is because ViEmu detects Visual Assist is present, it will decide to wait for VAX-hooking on all windows, and they will never actually get hooked, because the VAX has stopped working. It would be cool if there were a way to detect the VAX is non-functional, or whether VAX is planning to hook a given window, but unfortunately there isn’t (or I have failed to come up with one).

Ah the joys of 3rd party plugin compatibility.

This entry was posted on Friday, December 7th, 2007 at 12:22 pm and is filed under misc. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.