Ruminating on Text Editors

November 25, 2009 — Code

I write code primarily on Ubuntu, and I mostly use the included (and very extensible) GEdit text editor for writing code. A week ago I started playing around with using GVim, which I discovered when I installed Karmic Koala (I knew about Vim, but not GVim). I let the experiment go a little longer than I originally intended, and yesterday I decided to “stop screwing around” and go back to GEdit. Moments later, to my surprise, I realized that GEdit is annoying.

I’ve never been a fan of the mouse, which seems a rather primitive input device that has been lucky to survive this long. Many of the things we do on computers are done faster using linear navigation (cycling through a list of choices), and most tasks that do require two-dimensional movement (eg: drawing) are performed more comfortably with a pen and tablet. (I often wish for a good alternative to the free-floating window model, but I’ve not yet seen a “tiling” window manager that’s adequate.) Also, who wants to use two separate input devices? For reasons of speed ergonomics I’d really prefer just one.

Anyway, I originally learned Vi out of necessity—I was working on machines where it was the only text editor installed. Over the years I’ve used it from time to time, trying to keep the obscure commands in memory more out of some sort of geeky pride than of necessity (one can use Pico on a headless machine, right?). But this week, after learning some more useful commands like “fx” for jumping to the next occurrence of “x” and how to yank (copy) and paste, I find I’m really enjoying the task of editing itself being a bit more programmatic. Rather than rapid tapping on the arrow keys or moving a hand to the mouse and aiming: stop, take a breath, figure out where you need to go, and use the correct command to jump there. It’s frustrating if you treat it like a GUI editor and use the arrow keys, but gratifying, and much faster, to do it The VI Way.

My biggest complaint with GVim so far concerns the management of multiple files. This is a problem with every editor I’ve used, and I’m wondering if a radically new design is in order. Tabs along the top of the window are generally no good, because if you open too many files you can’t see them all (and eight or ten files is not nearly enough for programmers). This problem is solvable by auto-adding a row of tabs but the editors I’ve used don’t do that, and you’d still have to go to the mouse to switch. With GEdit you can get a vertical listing of open files along the left-hand side of the window. This works well, but it’s unstructured (doesn’t show where the files are) and doesn’t provide any easy way to open other files. The TextMate editor for OS X has a good solution to both of these problems with it’s project drawer: a collapsible directory tree which can be used for opening files. TextMate also has a row of tabs at the top listing the currently open files. This is all good, but you still have to use the mouse. There’s a GVim plugin called NERDTree which gives you a similar directory tree navigator, but GVim has the not-enough-tabs problem and NERDTree itself doesn’t offer a solution.

I’m not sure what the answer is to all of this. I use a dual 24" widescreen monitor setup and my vision is always filled with windows. If I work on a laptop I make copious use of “extended desktop” features. Maybe there’s a better way, but I find that the more I can see at once, the faster I can see connections and solve problems. If I can’t see multiple files at once I need to be able to switch among them rapidly. Perhaps the solution is to open multiple text editors so less file switching is needed, though that sounds confusing. Maybe a split window is the less confusing equivalent. I don’t know. At this point all I’m suggesting is that there’s a market for a radically new approach to file editing for programmers.

And it’d be great if it didn’t use the mouse.

comments powered by Disqus