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 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).