First off, I apologize. This blog got too long to edit and spellcheck somewhere along the way, and I need to get to work. So the quality of writing here is probably even lower than usual, if that's possible, as I haven't even lazily proofread it like I usually will.

Found this blog during a search on Google for vim and Eclipse. It had a link to a site called JavaBlogs which in turn led me to this reltively interesting comment on yet another blog (boy these things are like roaches! Yes, that comment would certainly include this blog as well):

I liked his comments (scroll down a bit) about the "Java Stigma" in terms of being able to do client apps. I'll throw some more points out there... Try using JBuilder or IDEA. These are monster client apps, written in Java that both look and feel excellent. People really need to get over the idea that Java desktop apps are either slower or look crappy.

Couple of comments. Swing (Java GUI tech I've been ranting/whining about) is slow, both to display and to develop. Apple has gone to great lengths to hardware accelerate Swing on its already horrible slow platform, and IBM's SWT is just another attempt to speed up a slow system. Remember, the question's not so much "Is Swing fast enough," as it is, "Is Swing as fast as the native apps the user's used to using?" Often -- usually -- the apps are noticably slower. Processors have gotten fast enough that many "day-to-day" activities in a Swing app might not be as noticably slower as they were before, but there's always some tell-tale sign, from startup time to a cluttered GUI causing slow-down or too many widgets updating at once that pegs the processor and kills other running apps (mp3 players being one really clear indication of when the processor is swamped).

Swing is also slow to develop for. It's not intuitive. And this is both on the design side and for users. On top of its goofy, roll-your-own event handling (admittedly I over-whined a few days ago, but it's still not good), a good developer needs to try and force Swing's square peg into the round hole of native OS expectations its end users have developed.

Also recall that JBuilder and IDEA are apps written for pretty techno-savvy users. Limewire is about the only Java-made client app I can think of that gets lots of real end user use, and I believe its success comes more from its kissing cousin relationship with the Gnutella protocol than any great user experience. (Furthur is another neat client app, but it's pretty unprofession-looking when it comes to UI, and isn't nearly as widely used as Limewire).

Geeky users don't have these native OS expectations and can adjust when you, say, have to use "Ctrl-S" to save instead of "Apple-S" or when other keyboard shortcuts don't behave as they do natively. Heck, even hard-core technie Joel Spolsky whines about UIs that are marginally different xplat (though I believe he's got a bit of "dementia-level perfectionist" in him). Here's a comment he made recently about XUL and Mozilla:

Even my favorite bugaboo, Alt+Space N to minimize a window, works in Mozilla; it took them long enough but they did it.

So that IDEA and JBuilder seem like decent client apps to a programmer isn't a good measuring stick on the successfulness of Java for the typicaly home PC user. Between Swing's inferior performance to native, the difficulty in producing a good, native-like user experience, and the yet unmentioned-if-farily minor pain of getting a JVM onto a user's system, Java's still not quite ready for the client-side prime time.

Note that these issues are part of why I think Sun should try harder to promote a Java platform that doesn't try to act percisely native and where users expect Metal Look & Feel application and expect to use Control as their main modifier key, expect to use JFileChooser to open and save files, etc. I've always wished Sun would make a Java OS and release it for x86 hardware with highly optimized calls, not so much to make money but instead just to make a point. Java is an OS, a look, another platform.

*sigh* Shifting gears...

At any rate, was originally searching to try and see if there's any way to integrate vim with the Windows version of Eclipse, which apparently claims somewhere to support OLE compatible editors. Course even if I could get it working, I'm pretty sure it'd be as unpleasant an experience as hooking it as the editor in Visual Basic 6's IDE. The files don't open up in vim in the same mutli-document interface, but instead, when a file is double clicked in the IDE, they are opened in a new vim instance. Not the best thing I can imagine.

I'd like to find some time now to write up some Java vim clone that just supports the commands I use about 70% of the time, like s, p/P, r, ^, $, y, and v. Of course supporting :w is pretty important, and is not supported by the crappy Java vim clone that I can find on sourceforge right now. That editor apparently is only really targetted for JBuilder as well, as far as I can tell.

That said, its activity percentage is above 50%, which isn't bad. But as a standalone I've found jVi to be nearly useless.

At any rate, I believe it'd be relatively easy to write an event listener for text widgets that would, if designed to be from the start, be pretty easy to port to C# and Windows Forms as well. I'm awfully confident #develop wouldn't have much problem integrating with the new editor, though editing Visual Basic 6 wouldn't benefit much at all I'm afraid. Hopefully, though I haven't read much about SWT other than a few "What is SWT all about?" kinds of docs on Eclipse.org, it'd be easy going to get the event listener going there too.

Guess I'll put that project right behind porting Futhur to OS 9, writing an Atari game, finishing up the Java app to help port to Java 1.1, and taking a nap.