Today one of the python blogs I read posted about an article they thought was the "Best Vim Article Ever". It has convinced me to (as often as possible) use vim for the next three months and see if it sticks.
-tinjaw
Darn, this is the best Vim article ever! It almost convinces me to give it one more try - although in the case of (g)Vim "try" is probably not a good strategy. A better idea would be to erase all other editors from the system first
I recall the last time I gave up on gvim was when I was reading through the manual and found a section, not too far into the document, about how, if you want to sort text, you can invoke the shell and run the sort command. I stopped reading at that line, uninstalled the whole thing and promised myself never to waste time with 30-year-old Unix tools again. It reminded me of Linux users ridiculing Windows for requiring restart on driver installation, but when I first installed RedHat (granted, about 10 years ago) I had to recompile the kernel before it recognized the sound card - at least the docs said it had to be done.
Still, the article is really informative as far as evangelizing goes. Unlike the author, I really have no trouble with finding arrow keys on my keyboards, but it does makes me yearn for the power of navigation. If only it weren't so ugly and angular
So here's an idea that I'm sure Vim people will totally scorn, but let me try it anyway. How about reversing the Vim paradigm and have a GUI editor that behaves in standard Windowsy ways, but also includes a command interface? It would be a little more verbose than Vim, of course: hit ESC to enter the command mode, type the command, press Enter to accept it. (This is your clue to start ROTFLing!)
At one point I did exactly that for my abortive attempt at rewriting KeyNote. I wanted to make the UI entirely configurable and scriptable from the word go, so nothing was hardcoded. The menus were built from XML files, and all commands had textual representation. There was a command handling engine patterned after Windows message passing mechanisms, which meant that the engine didn't care where the commands were coming from: menus, keyboard, scripts or macros, and macros could be easily recorded and replayed. It was really nice, because there was really no distinction between built-in commands and macros or commands with custom parameters. The regular File|Open command would be something like {cmdOpen} for example, and you could add {cmdOpen file="foo.txt" readonly="true"} as a menu item anywhere. Some parameters had default values and were optional (here: readonly), others required a value (here: file), so if you wanted to have a custom Open command that would always open a file in read-only mode, you would specify {cmdOpen readonly="true"}, and the program would prompt you for all the missing required params.
So while I was testing this, I added a command line to see how various commands were interpreted. Now, this particular implementation was of course awfully verbose, because it was meant to be used in UI layouts and scripts. You would not normally want to type {navigate direction="right" distance="42"}, but the principle remains. Apart from the lengthy typing, it was a fun way to use a program, and certainly great for debugging the command handler. Given a suitably concise command language, perhaps modeled after Vim, might it not be an interesting way of providing some of Vim's keyboarding power while not forcing users to abandon the familiar GUI-ness of Windows programs?
