Monday, September 10

a word about multi-file projects

(Chopped out of an earlier post and modified slightly.)

I've been living in Bash & Vim since I was about 19, and I am getting tired of typing. Part of a solution to this, is of course, making better use of the facilities at hand: Script more, use better editor macros and keybindings, remember that ctags is there, write Makefiles, get better with find(1) and xargs(1) and Perl one-liners.

But it's also starting to feel like, at this late date, part of the solution should be graphical. The last IDE I used seriously was Microsoft's QBasic, unless you count things like mIRC's built-in scripting, but I'm finally starting to be a bit jealous of basic features of contemporary IDEs like Eclipse.

Specifically, when this thing you're working on is spread across half a dozen different kinds of file (schema, HTML template, Perl, CSS, JavaScript, PNG), it can be amazingly useful to have that clickable/collapsable list of project files ready to hand. Likewise for painless tabs and visual bookmarking. Arguably these aren't really IDE features so much as they're the kind of thing you get if your editor grew up in a graphical environment.

I've been messing with a Vim plugin called Project for the last couple of days. It's essentially some folding and keybindings wrapped around a structured file, so that

FieldTrip=/home/bbearnes/fieldtrip CD=. {
  FieldTrip.pm
  pages=pages {
    frontpage.html
    header.html
    footer.html
  }
}

gives you a double-clickable list of files in a project. The interface breaks in a couple of places, and Vim's fold highlighting has always annoyed me, but this is probably 70% of what I want. I'm not sure how easy the other 30% will be to come by. Maybe I'm just wishing for a gvim which feels more native to its environment, or a file manager that knows how to talk to vim.

There's an argument to be made that much of the physical effort of using software emerges directly from the costs and requirements of holding things in memory - entities, paths, context. You wind up maintaining a complex mental model of system structure and state and physically navigating the system by reference to that model. Where there's rapid access to some kind of broad visual overview, I think you can shortcut a lot of that.

This has got its own set of problems, and you can have my xterm when you pry the keyboard from from my cold, dead hands - but it seems obvious that GUI approaches to context-display can be a lot less costly, where you've got a lot of context to display. How many times do I needlessly type "ls" in a given day, and why do I spend so much time specifying and navigating between discrete elements of a hierarchy or graph?

The rodent has long had a considerable advantage for things like continuous input, navigation, and selection. The people who brought you the Macintosh weren't exactly wrong about these things, they just insisted on throwing out the command-line baby with the bathwater, and somehow we're all still living with the consequences. Or at least we are on the level that most people interact with a filesystem.

Counterexamples do multiply, because the best interfaces in certain domains seem to independently arrive at some kind of hybrid model: Nobody played Quake with a keyboard alone (well, nobody sane), but Quake was a deeply good interface as much because it provided a builtin console and scriptable keybindings as because of the fluid and expressive mouse-input model. Similar things can probably be said about certain IRC clients, or the browser URL bar (the command line triumphs by stealth).