Nerdcore 4 Life

I’ve been getting more and more heavily involved in Vim recently(in no small part because I’m avoid doing actual work) and I’ve been ruminating on what’s wrong with it. It has 2 seemingly obvious flaws, it’s not graphical and it’s not intuitive. But I’ve come to realize those aren’t so much flaws as a consequence of design. You can’t fix those without breaking Vim. The real problem, however, is something eminently fixable if someone sits down and doe s the work.

The Red Herrings:

Firstly, it is true that Vim is not very graphical. Even Vim’s well to do cousin gVim makes using the mouse regularly a painful experience. And the feedback is entirely textual, with coloring of syntax being as much as you’re gonna get. But even though that’s a response to the limitations of terminals that Vim originally had to run within, this system has some advantages.

Coloring of syntax is about as graphical as you want to get. Typesetting and fonts give useful information to clue readers into how to interpret their text, but just get in the way of editors. They force the editor to make choices about what should be emphasized or stand out. These are not things you should be focused on while coding.

And while using a mouse as a primary input device seems to be the way to go these days, it has some real drawbacks. It slows down advanced users to the point of tears, and in a text editor it creates lots of ‘switches‘, places where I have to move from 2 hands on the keyboard to one hand on the mouse, one on the keyboard. That kills flow.

Secondly, while Vim is unintuitive due to it’s modal way of doing business that’s not a bad thing. People aren’t used to modal tools but if you told someone that they had to design a program that kept a users hands on the keyboard at all times(preventing ’switching’) there’s only 2 solutions you would come up with. Modal(like Vim) or meta keys(like Emacs). I doubt people would call holding Ctrl-Alt-Shift-X to move around intuitive.  Nothing intuitive can keep both your hands on the keyboard because users are used to mouse based, graphical interfaces.

The Real Issue:

So what is Vim’s big flaw in attracting new users? Discoverability. This is a concept that’s explored quite a bit in The Art of Unix Programming (one of my favorite books of all time). Good systems should be discoverable, the user should be able to learn new ways of using them within the system. If a program is hard to use and unintuitive but still discoverable, the user will learn it(as long as the tool is better than what their using, which Vim probably is).

To me discoverability entails 3 things:

1. Help is available, thorough, contextual and easy to use. Vim’s help is available and thorough, but falls flat on other accounts. There’s nothing built in to give you help on whatever it is your currently working on(like hitting <F12> on the command line if you start typing :%s/ ). And it is far from easy to use. It’s set up as a series of related text files that tie into each other, but finding a help term that gets you near what you’re looking for is nearly impossible. For example, what if you find ‘:set <M-x> XXX’ in one of your scripts? There is no way to find out what’s going on there.
2. The system is easy to experiment with, with no penalties. Now here Vim does quite well, except for finding what you want to experiment with. Which leads to
3. The system is consistent and builds upon itself in a meaningful way. Here’s where Vim really craps it’s pants. Within certain sub-sections it’s consistent, but across the board it’s not.What shows me all the current variables? ‘:let’ Oh, except for the Vim options, they’re under set. So I should type ‘:set’, right? Actually it doesn’t list all of them, for that I need to use ‘:set all’. Oh, except for termcap options which are under ‘:set termcap’ or any other option sets they decided to make separate which I may not know about. It’s difficult to discover information about my system when each way of querying is different.

Now I know why Vim is this way. It’s a program that’s been ‘grown’ over 20 years and things get added one piece at a time. But I think that it’s about time Vim was refactored with the goal of having a better user experience overall. I suggest(in no particular order):

1. A unified, searchable help database built into Vim(EDIT:turns out this is on the Vim ToDo list) and preferably crowd sourced. I’m tired of struggling to do something for hours, poping into #vim on irc.freenode.net and someone just says :help XXX and I find the solution right away. Vim’s helpfiles are great, I just need a way to get to the ones I want.
   And building in crowdsourcing would be a huge boon. if someone searches the help files, a way to indicate that a particular page answered their question could be massively useful data. Again this should(ideally) be built into Vim.
2. An easy way to source the current buffer so I don’t have to save it to a file every time I make a change. This would only speed up script writing, but anything that tightens the read-eval-print loop is welcome.
3. All variables, functions, options, etc stored within one dictionary. Currently this is how global, local and script variables work(for example g: is a dictionary you can search or step through). As a caveat to that I’d like options to go from being some special variable to just another variable set(so I could use ‘:let o:sethidden = 0′ instead of ‘:set unhidden’ which is weird and inconsistent.
4. Examples. This is the one place that the current helpfiles need more content. Every command/function should have examples for every option. The help could even have a howto.txt set up similar to a faq, making it easier to find the help the user needs within the tool itself.
5. Get rid of the function/command distinction. Either pick one or do the perl thing where the parens are optional. Having to write a command to call a function, having some functions called by their placement and others need to have the :call placed in front, all of this makes VimL less consistent.

Whoa, this turned out longer than I thought. I’ll stop here since I have no power to make these changes anyways, but I think it’s a good start toward fixing a lot of Vims real usability flaws and getting programmers on board with the greatest editor ever.

I recently asked this question on Stack Overflow and man, I am now seriously tempted to see what it’s like to build a byte code compiler. As I mentioned there, I have built a compiler before(for school). It was a trivial example and I remember that taking an obscene amount of time.

Fleshing out the VimL language with a byte coder is insane. It’s years of work when I have other things I want to do and other things I need to do. Most people don’t write VimL code long enough to get an advantage from it to begin with.
But still, the thought haunts me.