ViEmu Blog

A few days ago, I received some feedback that ViEmu/VS’s compatibility mechanisms for Resharper didn’t work fine with Resharper 3.1. Off I went and investigated it. It turns out that the latest version uses different internal names for the commands ViEmu intercepts, and thus I had to update the interception code to recognize the new names. Don’t worry, this is in addition to the old names, so now ViEmu/VS is equally compatible with all of them. Here is the new build, 2.1.21:

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

You need to manually uninstall the previous version before installing this one.

What the compatibility code does it it detects when the Resharper ‘Rename’ command has been issued, and if this is an ‘inline’ rename instead of a dialog-based one (which, afaik, only happens with local variable renames), it auto-enters insert mode. This works nicely, except for two glitches which are pretty hard to solve:

• If you issue the ‘Rename’ command by first using the Resharper ‘Refactor This’ command, which pops up a small command list, ViEmu can’t intercept this. It’s not a VS command, but some internal Resharper mechanism, and there is no way to intercept it that I know of (I did ask the Resharper devs about this, and I didn’t get any usable suggestion)
• Also, when renaming inline in insert mode, Resharper is kind of ‘king’, so if you press Esc, it will cancel the rename. You need to press Enter first to accept it, and then Esc to exit insert mode. It would be good to accept it with Esc, but it’s beyond ViEmu’s reach (it’s Resharper handling the Esc keypress)

All in all, it ViEmu should work a little bit better with Resharper now. Drop me a line if there are more glitches that need some care, or if you have any suggestions to the above issues.

BTW, for those of you reading this through an RSS reader, be sure to visit the blog to enjoy the new look, as I have styled it according to the rest of the ViEmu site and integrated it properly in the navigation bar, etc… viemu.com now looks so much nicer with all the pages, the forums, the blog, etc… all styled and integrated properly!

I’ve spent the past few days tracing code in assembly like crazy to address several issues. Some of them caused by my recent acquisition of a new laptop with the flashy Vista (I will probably post about the horrible experience at http://blog.ngedit.com, including some amazing workarounds I had to devise). But some of them were in order to solve some compatibility issues with DevExpress’s Coderush with ViEmu for Visual Studio (as reported by a user here in the ViEmu forums). The bad news is that I almost got crazy in the process. The good news is that I was able to find a work around and release a new build of ViEmu/VS (2.1.20):

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

It’s necessary to manually uninstall the previous version of ViEmu/VS before installing this one.

The bug was reported as Visual Studio 2008 crashing if some specific Coderush refactoring was used, a certain specific way of exiting the refactoring-mode was used, and then you used ViEmu’s ‘u’ to undo the action. It took me a couple of days just to reliaby reproduce the bug, mainly because Coderush refused to work on my new Vista laptop. I googled for solutions to the problem, and sure enough I found someone else reporting it on the Coderush forums, but the DevExpress developers had been unable to reproduce or fix it. I finally found a blog post by emad providing a solution, so I was able to install Coderush on my laptop and reproduce the problem. I tried to post the link to the Devexpress support forum, but they almost wanted me to provide my mothers maiden name to post, so I ended up not contributing the solution (hint hint).

After reproducing it, and debugging an instance of VS 2008 with a debug build of ViEmu and Coderush install, I found out that the call that ViEmu does to perform the undo (IOleUndoManager.UndoTo(pUndoTo)) triggered a crash, with the following call stack:

msenv.dll ! NEnvMsenvTextMgr::CGlobalUndoCoordinator::SavePendingTextBuffers()  + 0x384
msenv.dll ! CMultiDocUndoParent::Do()  + 0x22d
msenv.dll ! COleUndoManager::UndoTo()  + 0x7b
ViEmu.dll ! VSBufAccess::Undo()
ViEmu.dll ! ViOpControl<>::Undo()
ViEmu.dll ! nglib::ViCommandControl<>::Undo()
ViEmu.dll ! nglib::ViCommandsImpl<>::CmdUndo(nglib::ViTrackCommand<> * pTrack=0x0012d724)
ViEmu.dll ! nglib::PerformCommand<>(nglib::ViCommandControl<> & control={...}, nglib::ViCookedCommand<> Command={...}, bool doing_dot=false)
ViEmu.dll ! nglib::ViCore<ViCoreControl>::ExecCommand<>()
ViEmu.dll ! nglib::ViCore<ViCoreControl>::CoreProcessKey<>()
ViEmu.dll ! nglib::ViCore<ViCoreControl>::ProcessKey<>(nglib::key_win32w k={...}, ViOpControl<> & OpControl={...}, VSCaretOps<> & CaretOps={...})
ViEmu.dll ! TInterceptor::ProcessKey(nglib::key_win32w key={...})
ViEmu.dll ! TInterceptor::SubClassProc(HWND__ * hwnd=0x00270a36, unsigned int msg=258, unsigned int wParam=117, long lParam=1441793)
user32.dll ! _InternalCallWinProc@20()  + 0x28
...

What this means is that ViEmu’s call to undo was triggering some internal pending text buffer save, which was crashing. I was also able to reproduce it with VS2005, so the issue had been lurking in there for some time. I tried all sorts of workarounds to try to force a ‘flush’ of the pending state before doing my call, but in the end I found that the only way to avoid it was to do the ‘undo’s by calling DTE.ExecuteCommand(“Edit.Undo”), rather than the internal IOleUndoManager.UndoTo(). The problem is that using the DTE method doesn’t allow me to specify which or how many actions to undo, which is key to proper vim-like undo emulation (a command like “cwhello<esc>” has to undo both the typing of ‘hello’ and the deletion of the previous word). In the end, I could do a manual inspection of the stack combined with a DTE call for each undo step, which worked around the issue reliably.

This is one of those cases where I like to think that it’s not a ViEmu bug, but one which was hiding inside Visual Studio and only triggered by the pretty sophisticated use of VS that ViEmu has to do. I could have probably recreated the bug by generating a new add-in with one button and 3 lines of code that called the internal UndoTo(). I’ve done that kind of thing in the past to report issues to Microsoft. But since neither MS or DevExpress are likely to release timely fixes, I just went straight to finding a workaround.

Anyway, the new versions is up there for download to interested parties, and I’ll be testing it myself intensively to verify that the new way to do undo grouping doesn’t cause any unwanted issues, and promote this to the official 2.1 build in the near future. Meanwhile, I’ve found a few issues between VS2008, Coderush and Codekana that I need to address, and someone dropped me a line that ViEmu’s Resharper compatibility measures are not doing very well with the latest Resharper 3.0… thus is the life of a plug-in the developer.

Happy New Year everyone, and I hope 2008 will be full of success for all of you and your own projects and void of any new compatibility problems for ViEmu! 🙂

As explained yesterday, I’ve just built and uploaded ViEmu/SQL 2.1.18 making installation fail-proof for Vista. No other changes, so you don’t need to update – but hopefully the installer will get ViEmu/SQL to start working more reliably on all systems.

I just built & uploaded ViEmu/Word&Outlook 1.0.24, and made this the ‘official’ 1.0 release at the same time (that is, if you go to the ViEmu home page and click ‘download’, this is the build you’ll get). The ViEmu code itself is the same (with just a new 1.0.24 version tag), only the installer has changed.

The fix to the installer is to make it write ViEmu’s COM class registration info to HKEY_LOCAL_MACHINE instead of HKEY_CLASSES_ROOT. The original behavior could sometimes result into ViEmu not loading in Word & Outlook at all, when installing under Vista. It was weird, and difficult to figure out. Only after I could reproduce it in the new Vista laptop I got last week I could properly investigate it. It turns out that, under Vista, entries written to HKCR are redirected to the per-user HKEY_CURRENT_USER, unlike under XP. I believe that Word should still work fine, but it seems sometimes doesn’t. The design behind the registry, the Windows installer, the COM architecture itself, and the Word add-in model are so bad that you never know what may be happening. Anyway, this shouldn’t happen anymore with the updated installer.

I don’t know why this happens in some Vista systems and not on others (actually, it just works fine most of the time). I won’t bother to investigate the exact reason, as the new installer system makes sure that registry entries are written to the best place and the whole issue is sidestepped (and I’m not keen on investigating Vista’s quirks more than strictly necessary).

In the next few days, I will prepare an updated ViEmu/SQL installer with the same fix. ViEmu/VS is unaffected because it’s a VS ‘package’, rather than an add-in, which doesn’t use the regular COM registration mechanism.

By the way, I’ve started using Vista full time on my laptop. General impressions are good, the fact that VS.NET 2003 is not supported and freezes as soon as I do a “Find in Files” is not nice. I will move all my projects to build using VS2005 at some point in the next few weeks, but for now I’m doing pure development inside an XP VM. VS.NET 2003 has remaind nice & stable and I just prefer not to upgrade unless there is a really compelling reason.

A couple of things I just posted about on the ngedit blog:

• I’ve changed the design of the ViEmu home page to include a sidebar with goodies, including a link to a new testimonials page. Read about it here.
• Aaron Jensen has put up a cool screencast teaser for some vi/vim tutorials he’s preparing. A link and more details here. Awesome!

One recurring complaint about ViEmu/Word&Outlook is that its status bar obscures the bottom side of the document being edited. The status bar is the pale yellow line that shows the current mode (“–NORMAL–“, for example), and partially typed commands (be they normal mode commands, ex commands or even ‘/’ or ‘?’ searches).

This problem is more severe with Outlook, because Outlook disables scrolling beyond the end of the document. Technically, it’s because Outlook  uses the “Web layout” view mode of Word’s visualization engine, which causes this problem. But anyway, Word editing is usually done in “Print layout” or “Normal” view modes, so you can always scroll a bit to unobscure the area of interest.

I’ve been researching methods to avoid this problem. The main possible solutions I’ve come up with for Outlook 2003 revolve around putting the status bar somewhere else – namely, on top of Word’s own status bar, or on top of a special toolbr which would be docked at the bottom of the editing window. I’m investigating using the Word status bar first, as this looks more sensible and sensible. I’ll need to put the input somewhere where it won’t obscure the built-in status bar information areas, which will probably involve pushing to the right. Not the best solution, but possibly fine.

I already have some prototype code mostly working in this way, and it definitely helps. I still have to make sure it handles all conditions correctly, that it works fine with split-view windows, etc… It will all be configurable in the end, so it will only be a net win.

The best solution would be to stash it in a dockable toolbar, but I’m not all too sure whether I can configure a special control on one of this toolbars. I will investigate it though.

The main problem with this approach, though, is Outlook 2007. Outlook 2007’s mail composing window is actually a kind of container for a Word-engine window. It works fine, and it’s actually cleaner than the way Outlook used Word in previous versions, but it also means it uses Word 2007’s ribbon interface. And here comes the problem: I have been unable to make it show either a status bar, a toolbar docked at the bottom, or anything else for that matter. This means there is no place where I can overlay ViEmu’s status bar. I’ve gone through Outlook’s mail editor settings several times now, and I’ve found no “Show Status Bar” option. Bringing up a toolbar also seems impossible – the current interface paradigm seems to have gone out of its way to remove them.

One possibility is to have a “floating” status bar below the window. It would be a top level window, which would probably have to disappear when focus is lost by the editing window. This will not be nice, but it will work – as long as you don’t maximize Outlook. If you do maximize it,  then the status could end up anywhere: on top of the horizontal scroll bar, on top of the windows task bar… who knows.

Anyway, if anyone of you has an idea on a better way to approach this, please share it with me.  This is something I want to address as properly as possible, and I’ll be happy to give some thought to all suggestions.

Once this issue is addressed, I plan to do a few improvements to ViEmu/W&O and release version 1.1. It’s about time ViEmu/W&O leaves 1.0 status (technically, it’s in 1.0.23 now, so a far cry above a fresh 1.0 release, but anyway).

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.

I’ve just tested ViEmu/SQL Server with the latest CTP (‘Community Technology Preview’) of SQL Server 2008, codenamed “Katmai”. This latest CTP was released in November, and the final product is expected to be ready some time in early 2008.

The latest build of ViEmu/SQL on the web site (2.1.15) didn’t work right away, but it was just a matter of upgrading the installer to write its registry settings to the specific hive (branch) for the new product. I did just that and it works like a breeze. I’ve built a new revision, ViEmu/SQL 2.1.16, which hooks itself both into SQL Server 2005 and SQL Server 2008. I’ve just uploaded it:

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

Remember, you have to manually uninstall the previous version of ViEmu/SQL before installing this one.

I will promote this build to ‘official latest’ after it’s been up for a few days.

It’s very likely that this will be the only change needed to make it work with the final build of SQL Server 2008, but in any case I will watch out for any changes that require upgrading ViEmu. Just drop me a line if you stumble into a problem.

And happy SQLing with vi/vim keybindings!

Someone asked about whether ViEmu would work fine with the new VS2008 in a 64-bit environment. I just tested it today, and it works just fine. The installer complained about a failed operation at the end, with Vista whining about it “requiring elevation”, but I just clicked ok, started VS2008, and ViEmu was there fine. I’m still quite puzzled with Vista’s byzantine and seemingly useless security mechanisms. Hopefully I’ll understand them better as time passes. But meanwhile, all of my products seem to work fine under both Vista x86 and Vista x64. Drop me a line if anything causes trouble.

Yesterday, I posted a funny story about the Vi Gang Sign to my NGEDIT blog:

http://blog.ngedit.com/2007/11/19/the-vi-gang-sign/

I thought I’d link to it from here in case you’re interested (not fully ViEmu-related, but definitely vi/vim-related).