April 17, 2010

Vim and Emacs – When Programmers Design

There are various immortal battles of loyalty — Coke versus Pepsi, Kirk versus Picard, McDonald’s versus Burger King — but the one closest to programmers’ hearts is Vim versus emacs. Vim and emacs are text editors dating way back. Vim (as in VI Improved) is a “newer” version (as in only ~20 years old) of VI, which was originally written for BSD UNIX in 1976 and is a staple of terminal applications. Emacs is the brainchild of open-source pioneer Richard Stallman that same year.

Why are these crusty old terminal programs so near-and-dear to coders? The short answer is that they work. What they don’t do, however, is make themselves accessible. I’ve been jumping back and forth between both over the past few weeks, and simply put, this is what happens when you have programmers design software, and not just write it.

What I mean by that is there’s no denying the power of both editors. There’s a reason they’re still used, still maintained, and still invaluable. That said, there is simply no concern with making the applications intuitive, user-friendly, or out-of-the-box ready. If you’re going to make significant use of either, not only will it require significant time investment and the effort of learning not only the basics of how to use them, but the features that make them worthwhile, but also the investment of configuring the software to actually be practical for what you need.

The majority of my programming of late is with PHP-based websites. This means writing PHP mixed with HTML, as well as CSS and JavaScript files. Neither do this properly out of the box, and frankly, there isn’t a good solution for PHP mixed with HTML in either. There are relatively poorly performing add-ons that do the job, but not as well as they should.

One could argue that hey, don’t bloat the software. I may want that, but not everyone will. I’m not one for bloat, but there is consideration for convenience versus leanness. It’s part of the reason I use Opera over Firefox — it’s built-in, with no other maintenance required. Given the scope and use of Vim, I don’t think it’s an egregious request that it have more universal options out-of-the-box. Emacs is a 40MB download, so I hardly think fleshing out of the language support is too much to ask, either.

Let’s be realistic here. It’s programmers using this software. Why on earth do these programs have syntax highlighting disabled by default? Why are line-numbers disabled by default? Why does it require additional configuration, even downloads to get highlighting for popular languages?

We’re programmers, we fiddle, but that isn’t an excuse to leave software in a unfriendly state because you feel justified in saying “deal with it.” I do, and will continue, to use both programs; programmers handling design also means some awesome features — so long as you can find them.

Share this:

Like this:

Related

These are two time tested tools… they survive based on their functionality and flexibility. If they don’t currently meet your needs, take hammer to steel – resolve the issue to your satisfaction and share your work. This is open source. Don’t spend your time complaining about free tools not tailored to your needs, it’s petty.

to start i’d just like to point that i find this unfair, vi(m) is an editor, emacs is an environment (some would call it an operating system) and does a heck of a lot more than text editing, from comunication to file and process management, calendaring, simple web browsing, documentation reader, emulation to the point that there are even vi(m) emulation modes for file editing, and so on.

long time emacser here (should be obvious by now, no? :), so i see this as nothing but clueless FUD, syntax highlighting is only off by default if you’re a dumbass using a 5+ years old version, line numbering should _not_ come on by default, emacs does a lot more than editing (ie. gnus, jabber, dired, tumme, docview, w3m) the last thing i need is some intrusive visual nuisance that even gets in the way of my regexps and macros, if i need or want it i’ll call it explicitly with the hook of the mode i want it active in (then again _I_ never need it, that’s what the modeline is for and if i want to jump to a line looking at the border and scrolling is by far the most inefficient way of doing it, so thanks but no thanks), as a final note php developing sucks even in php oriented ides so emacs actually does a pretty good job editing it with mumamo

if you do program for a living after the first 5 years of using emacs you’ll thank $DEITY for the old, crufty and uniform-across-platforms interface that won’t change with every new fad and trend in “usability” and actually let’s you get some work done instead of getting in your face and in your way with every new version