Today, I’ve gotten to the point where basic navigation keys work in ViEmu under VS 2010: ‘w’ to move to the next word, ‘0′ and ‘$’ for start and end of line, etc… it’s all very basic, but it’s a “proof of concept” and it hasn’t been easy.
This means I got to compile the vi/vim core in managed C++, a superset of regular C++ that targets Microsoft’s CLR (the .NET runtime). I am not compiling anything in “native mode”, all the code is now .NET managed code. I wasn’t sure this flavor of C++ would support all the things I do with templates, etc…
I had managed to avoid doing any .NET work at all until now. Now it’s the end of this “free ride” for me, so I’ve had to learn a few things. Also, mixing standard C++ classes with .NET-managed classes involves a few areas that are not very obvious. The help of several incredibly helpful people via Twitter has been key to addressing all of this: @tomasrestrepo, @TheColonial, @noahsmark, @richiehindle, @aaronjensen, @AaronMarten, @shanecourtrille and everyone else - thanks so much!
C++/CLI support in VS2010 is not as good as for C#. C++ is some kind of second class citizen in the .NET world. For example, there is no Intellisense support for C++/CLI in VS 2010. This is quite amazing, and a big loss when having to use an API you don’t know well, which is my case now.
Anyway, this is only the start. Any of the ViEmus is basically two parts: half of it is the vi/vim emulation core itself, which is shared between them all. It’s highly abstract C++ code, all templates, which is completely type-agnostic - it can work with any classes for character types, text views and buffers, host environment, etc… It stretches the abstraction abilities of C++ to the limit, so it can be somewhat baroque, but it has allowed me to have a first stab at a ViEmu for VS2010 in a couple of weeks, using exactly the same code as the old VS version, the Word version, etc…
But the other half is the integration code. Stuff like intercepting input, displaying the vi caret, hlsearch support, undo grouping, intellisense integration, window/view split manipulation, compatibility with other 3rd party products, etc… which is what gets you a real, high-quality user experience, and which takes as much work, if no more, than the actual core vi emulation itself. And the thing is that, for the VS2010 version, I have to reimplement all of it. It’s a huge amount of work, but I hope the result will be well worth it. I also hope this time around VS and the other 3rd party extensions will be less problematic to deal with than last time — but I may be in for some disappointment in this regards. I’m definitely implementing a few things in a different way this time, with the experience of what caused most trouble before. The input interception will definitely be different - some of its edge cases caused a lot of support issues.
This time around, as well, I’m incredibly lucky to have some quality attention from Microsoft. Last week I had a conference call of over one hour with 6 (six!) devs from the VS team. It was a great experience, I got to share my issues, doubts, and even complaints with the people behind Visual Studio. They talked me into trying some more civilized approach to input processing, rather than the “nuke” level stuff I was planning to go for first (a message hook), provided some guidance for some the issues and just made me feel they value what ViEmu brings to the VS ecosystem — it’s a niche product, but it’s very appreciated by its users, and I’m happy to see the VS team acknowledging it and helping out so much. I’m also getting a lot of help on the VSX forum, via email, and even on twitter, so this time around, the experience of hooking into an MS app is being much more enjoyable than the previous times.
If I had to sum up what VS2010 brings in terms of the editor, I’d say MS has made great advances in the display and visualization side of things, there is also a much better thought out and designed architecture for the actual text and text editing management, and it’s only the input side of things that they have still left in a quite poor state, like it was in the previous versions. The move to WPF also means that traditional Win32 tools are not valid now, which is also problematic for input handling.
I’m doing ViEmu first, but all of the knowledge and at least part of the work will apply to porting Codekana. I’m leaving Codekana second for several reasons: it’s the less popular product (but I think this will turn around at some point!), there are less users, the integration is less complex, and I think I will be able to do everything I want just using the new editor’s MEF-based APIs, without having to resort to ugly hacks like is the case with ViEmu. Also, I think I will be able to obtain much nicer results in VS 2010, with much less effort, so I’m saving the good part for later
Again, I’m finding that Twitter integrates greatly with all my daily work, not as something that removes productivity, but as a tool to share the good and the bad, to reach out for help, and to be able to communicate effectively where I am and where my products are. Writing blog posts quickly becomes a chore, as I think of things to add and try to write well. 140 characters is great to keep things to the minimum, and lower the expectation about the form, so that you don’t waste time in unnecessary effort. I might blog occasionally, but I am in twitter almost daily. It allows me to stay in touch with peers, customers, MS devs, friends, and it makes the daily work more pleasurable thanks to the social aspect. What’s not to like? I totally understand the spectacular success of Twitter.
My twitter profile is http://twitter.com/jonbho, btw, in case you want to stay up to date on my progress.