(Motion Sickness

In which the author explains why Emacs and/or Vim are still the best programmer editors around - but maybe not for long. Includes a brief review of the Wing and Komodo IDEs.

I bought 2 IDEs recently

The Komodo IDE and Wing IDE were on sale at the Python conference. So I decided to buy Wing IDE - since it was fairly cheap, and I wanted to give some monetary support to people doing work with Python. Then on a whim I bought the Komodo IDE too because it was interesting to me that it is built atop Firefox, and, from a distance, seemed better than Wing IDE.

The use or non-use of an IDE is an bone of contention among some programmers. Oliver Steele talks about it in The IDE Divide. It is also discussed in Death to GUIs at the BileBlog. And Harry Fuecks has some more things to say about it (by the way, Harry Fuecks is a porn name if I've ever seen one).

Now, if you are reading this and you are not a programmer. Then you should probably stop reading this. But if you are reading this, and you are a programmer, and have never heard of Emacs, then you may wonder what the big deal is. What's the bone of contention? If you want to program in a language - there are products for that. If you want to write a program in Java - then there is Eclipse or IntelliJ or IDEA. If you want to program in C# then you have Visual Studio. Every language has it's product. Signing on to a language is signing on to a product and a company. There is some wisdom to this thinking.

On the other hand, there are a group of people out there - and I suppose I'm one of them - that are not that sold on or impressed by IDEs. Take my word for it. There are at least 100 of us.

If you have heard of Emacs then it may come as a shock to you that some people have not. I've met plenty of programmers that have not even heard of Emacs. I was surprised at first. I mean, I could understand not using Emacs, but never even having heard of it? But it is true, and an even greater percentage of people do not get it. And I don't say that disparagingly. They have every reason not to, because it sucks.

Emacs Sucks - Admit it

What is wrong with Emacs? Well Steve Yegge discusses some of it's shortcomings in The Emacs problem. So I will elaborate on others. And boil it down to six points. After which I will try, unsuccessfully, to convince you it is still the best thing out there. Which is more of a sad truth than something to celebrate. (90% of what I will say also applies to Vim - my actual favorite) The six points are:

1. Not easy to get started
2. Strange default keyboard commands
3. Obscure scripting language
4. In fact, just obscure - period
5. No centralized 'plugin' infrastructure
6. Debugger interface no good

Not Easy to get Started

Well, first - go download emacs. Oh, sorry. There's a possible snag right there. If your running Linux then your in luck! - it is already installed. Windows? Well - good luck. Search Google. You'll eventually find something. My favorite distribution for Windows™ is EmacsWin32 Because it has an installer and is running the latest CVS version.

Now that you have it installed, you run it - and to your horror it ... is ... so ... ugly. To tell you the truth I only have a vague memory of what an unadulterated Emacs looks and acts like. It's been 10 years since I've seen such a beast. I have 10 years of accumulated extensions hanging out in my home directory that customizes everything for me. But my memory is it's ugly - clunky looking - and doesn't do much of anything. There is probably a menu and a toolbar. So you can open a file. But that's about it. If your used to an IDE it is going to seem absurdly awkward and dis-functional.

Of course there is always XEmacs. It comes installed with a lot of stuff automatically - and a lot of people like it. I don't know why I've never liked it. Maybe because it comes installed with a lot of stuff automatically. But anyway, there you are running Emacs or XEmacs.

Strange Default Key Bindings

One problem you'll notice right away on Windows is Ctrl-x, Ctrl-c and Ctrl-v don't work as expected. Cut, Copy and Paste. You've used them 10,000 times in other programs. But now they mean nothing. And for that matter Ctrl-s (save). Also, the Alt key does not function as a shortcut to menus (unlike every other program on Windows). So Alt-F won't take you to the file menu. Which is usually the first thing I do in a new and unfamiliar program.

So you manage to open a file, type something in the file, and hit Ctrl-S. Like you've done 10,000 times before. And what happens? The cursor doesn't work anymore and you haven't saved anything. If your observant you'll notice something that says I-search: at the bottom of the screen. It's not a dialog box - it's just this strange area at the bottom of the screen (called the 'minibuffer' of all things), which, unbeknownst to you, has hijacked the cursor and should be the current focus of your attention.

It says I-search: coldly. What does that mean? It could could mean "internet search", it could mean "interactive search" it could mean a lot of things. There is no telling.

And god forbid if you hit Ctrl-x to cut text. Who knows what will happen. Maybe it will pull up a help page. Maybe it will shut down the entire program and leave you with an identical file with a "~" next to it's name. Maybe it will look like it's stopped doing anything at all.

That's because Ctrl-x is a keyboard command that is actually a prefix waiting for another command. So with Emacs you get a lot of keyboard mappings involving the Control key - multiple times. Ctrl-X, Ctrl-T or Ctrl-X, Ctrl-B sometimes even Ctrl-X, Ctrl-B, Ctrl-C, 3 pronged commands. People that don't like Emacs like to make fun of this. It annoys them because it's annoying. Especially if you don't know about it. Because once you hit Ctrl-X, it seems as if anything can happen. It all depends on what you do next. And since your confused, who knows what you will do next.

Obscure Scripting Language

The underlying language Emacs is written in and its 'Macro' language - is Lisp. This is problematic because no one knows Lisp anymore. Which is too bad because it's actually a good language. But it's housed in a lot of people's minds next to Fortran or Cobalt. Languages of long-ago. And if they have any experience at all with the language, their likely summary will be "too many parenthesis".

And if you want to learn the language so you can extend (e.g. make useful) the editor then your not going to get a lot of help. Your mostly on your own. There is an out of print book about it. And then there is Google. That's your help file.

In fact, just Obscure - period

Who uses the term 'buffer' when they mean 'file'? What other editor opens up a directory by opening up a text file that lists all the files in that directory (instead of your standard "Open File" dialog)? What editor is Ctrl-x h the 'select-all' command? The list can go on for hours actually. Everything about Emacs is quirky. And I agree with nearly everything in this Joel Spolsky article which states

"A user interface is well-designed when the program behaves exactly how the user thought it would."

According to that, Emacs is not a well-designed program. It does not behave exactly as you would think. Maybe it behaves exactly how someone thought 30 years ago. I don't know. But not anymore. If you tried to sell Emacs as a new product - no one would buy it.

Vim is even worse in this regard. Probably the king of "I didn't expect the Spanish Inquisition" behavior. If I'm planning on trying out a program, I don't want to hear "It's great - if you spend a few months learning how to use it". That means it's just a pain-point in an historic fraternal secret society that should be experienced just for the sake of making someone else re-live your personal pain.

I love Vim. Don't get me wrong. I just don't ask anyone else to use it. I prefer to lead by example (no one actually follows my example - but that's okay).

No Centralized 'Plugin' Infrastructure

Another problem is the chaos that is the Emacs microcosm. There are lots of great extensions to Emacs to be had. Where are they? Well, on the internet somewhere. Just search. "Seek and ye shall find". This is one of several reasons that I have a slight preference for Vim, because the Vim site has a scripts and plugins section. But then Vim can't quite do everything I need. Almost, but not quite. The fall-back is always Emacs - because it can. JEdit has a plugin website as well. But not Emacs.

By the way, if you add too many packages to Emacs - such as the god-awful JDE i.e. if you try to make Emacs look and act like a real IDE (since it is extensible right?) it really starts to fall apart. It is best to keeps things minimal. Spartan. It works best that way. Get rid of the toolbar. Get rid of the menus. Only load the packages you really need.

Debugger interface no good

Try debugging in Emacs. It's usually some command like pdb or gdb or what-not to get started and then Ctrl+Space for settings breakpoints. It never seems to work very well. It's probably just me - but I end up preferring a command line debugger. Which is real crude. Let me tell you. Running a debugger at the command line feels like I'm sending commands to a spacecraft .

So if it's so bad - why do you keep using it?

Okay - I've talked about how much Emacs sucks. What's good about it?

Well, as a disclaimer, it's not that I like it so much. I'd like to move on to something better. I really would. But I still can't. So what does it do that is so great? Why am I going to continue to use it? (and by the way - just like the bad points - 90% of the good points also apply to Vim)

1. I don't have to use mouse to switch files, open files - or for that matter, anything. To me using a mouse is a context switch and a waste of time unless x, y coordinates are actually vital information. I hate navigating tree-view lists of files
2. Speaking of which, it gives me a directory list that is just text so I can copy and paste it into a file. This is useful when I need to create a batch file that adds *.jar files to the classpath. It's also useful for documentation. It has unforeseen uses. A tree view has a total of zero unforeseen uses. No other editor does this for me (except for Vim)
3. If I hit Alt-X, I have access to all the commands the editor has to offer - and they are listed in a list that is limited by what letters I've typed in - so I can do a pseudo search. For instance, what is the command to put comment marks around text? I type in "comm<TAB>" - and get comment-region. If I choose the command it puts comment marks around text of any language I happen to be working with.
   
   

   Then it shows me this: "you can run comment-region with F9". Which is very useful. More useful then any menu system. Because a menu is another tree based structure - that only works for simple structures. Once it gets complex it takes a lot of drilling to get down to actual commands. And every editor worth it's salt is going to have way more commands than can be present in the menu system. So there has to be some way to get at them other than a menu.

4. It gives me tab completion (like above) except for everything - lists of files I have open, lists of files in a directory, lists of command available. This is great, because it minimizes typing. If I want to switch files for instance, I run C-x b (switch-buffer) and then type "ind<TAB>". Emacs will fill in the rest (in this case perhaps "index.html"). So if I type a few letters and cycle through every option that starts with those letters.
5. Plugins, extensions, macros - whatever you want to call them - are just scripts. You can write them without having to implement an interface or compile or any rigamarole such as Eclipse enforces. They are also easy to test in the editor as you are working, you don't need a special type of project, or contained environment to run and test things. You just type them in a text file and run. Simple. No restart. No nothing.
6. Stability. I can use the same scripts I wrote for Emacs back in 1999 - unchanged. And all the crazy scripts I've downloaded over the years still work - year after year.
7. I can open any file written in in any programming language - and it is colorized - and usually has some added functionality related to that language. There is always an Emacs mode for every language. Erlang. Haskell. Ruby.
8. I can to go to definitions of functions in my code - from where they are called to the file they are in. This is done by means of ctags so whatever ctags supports Emacs supports. Since ctags just generates a file - I can migrate to another computer and still use the same TAGS file. I don't have to have the IDE rebuild anything
9. I can customize the keyboard binding to my own liking - save that in a file and import it into a new version - on another machine - on another operating system. In fact I can run everything on Linux and Windows the same way - with the same exact configuration files
10. The extension language is a real language - used in other places for other things (as opposed to a fake language that is only used for writing extensions to an editor). Granted Emacs walks the line here a bit because the language is Elisp - a 'variant' of LISP. But at least it resembles a real language
11. I can run a command line shell inside a text buffer so I can save a command line session as a file - or paste in commands from somewhere else - such as from a tutorial or a help file
12. I can cycle through the list of things I've copied and pasted so I can paste something I copied a while ago - instead of just the last thing I copied. Office 2003 tries to do something like this with an extremely annoying list that pops up on the right-hand screen. Emacs is much more discreet about it
13. It has an Xml editor that gives me a list of what tags can go where (given a DTD or schema or something). In fact it has an Xml editor that is so good at contextual information that it compares favorable with any Xml editor you can buy - including XmlSpy or Oxygen.

I thought you were going to talk about Wing IDE and Komodo?

Of course I began this tirade talking about 2 IDEs I bought recently - Wing IDE and Komodo. Since I've just gone on for 30 minutes about how great Emacs is, you can hazard a guess as to how I feel about them. But I have to say - they are not bad. I could see using them, and I could see not feeling bad asking others to use them. And that gives me hope that someday we will finally move beyond Emacs.

What about Eclipse?

A lot of people say Eclipse is the new Emacs - but I don't believe them. Not yet. Too many tree-views crowding my view. Too little unforeseen usage. And it still takes 30 seconds to load on my laptop. I'm not exaggerating. I've counted to 30.

J is Better than Eclipse

And I'm not just bashing Java, because Java itself is not the problem. The J editor is a really responsive editor, that I used for a full year and was very pleased with it. The author seems lost in the morass of trying to implement a Common Lisp that can run on the JVM for the moment, but the potential is there, much more so than in Eclipse.

Good things about Wing IDE

1. The "Go to Definition" function actually works - and it will go to source code in the Python library. Without having to set any paths up or anything. This is great if you have everything installed in site-packages
2. Debugging works and is quick and responsive and convenient
3. The remote debugger is easy to set up and use
4. There is an area at the bottom of the editor in which you can run commands by typing them. And if you type the first few letters of the command and hit <TAB> it will give you a list of possible matches
5. Opens quickly - and is generally responsive and fast - despite being in Python
6. Interacts with Subversion
7. A lot of things are accessible by means of the keyboard

Finally, an Editor Command Runner

The area that accepts input to run commands in Emacs is called the 'minibuffer'. So I will refer to any area that is similar with that term. It's a little one line file that you can type commands in that the editor will execute - or in which you can type answers to questions like "save file (y or n)?". At first this seems absurdly archaic. But there are some unforeseen uses, the least of which is you can copy and paste.

Wing IDE is the only editor I've seen yet that makes this command line area adequately. A lot of editors have an area that is roughly analogous, but you have to use the mouse to get to it, it doesn't have tab completion, and is just generally inferior. I was very glad to see Wing IDE get this right - because I've never seen anyone else get it.

Good things about Komodo:

1. Warns you when you are overwriting an existing keyboard shortcut
2. Most everything is keyboard accessible. And the keyboard commands you expect - like the escape key to make a dialog box disappear, or Ctrl+Tab to cycle through a list of tab pages
3. Has an "export to html" function for code - that will output code the way it looks in the editor
4. Syntax highlighting for most languages - and extensions for things like Django. Including the ability to define your own
5. Set up to run and interpret external commands - such as make or runhaskell or whatever
6. Interacts with Subversion
7. Has a debugger that supports multiple languages

Bad Things about the Wing IDE

1. Can't effect syntax highlighting of all file types - so my Html looks really ugly and I can't do anything about it
2. Doesn't support as many file types as Scintilla proper. I tried to open a Haskell file and it didn't like that. Komodo did fine with Haskell
3. no "export to html..." which is useful for gathering syntax highlighted code snippets
4. Can't access everything via keyboard. Especially in dialogs - or the Help system
5. No tab completion in minibuffer when in 'Vi' emulation
6. No warning when overwriting existing keyboard shortcuts. This is a little annoying if I want to know if Ctrl-K is already taken or not
7. Not set up to run and interpret external commands - like make or scons or whatever command you might need to run
8. Having a GUI based on GTK is always risky, because it's a little clunky and awkward. And simple things - like hitting escape to make a dialog disappear, don't work they way you expect

Bad Things about Komodo

1. Debugger is slow, especially the remote debugger
2. Occasionally something is not accessible via keyboard. It's very close to being a mouse-free editor but I still can't get rid of the mouse entirely.
3. 'Go to Definition' doesn't seem to work for library code - so it doesn't delve into site-packages or site-ruby or anything like that
4. No tab completion in the minibuffer period
5. Remote debugging is cumbersome to set up and use

Better than Emacs and/or Vim?

No. Not yet. But they are getting closer. Year after year they get more and more things right. And less things wrong. Yet they still have not matched the functionality of Emacs or Vim. Why is that? Is it that difficult?

I'm glad to see both Wing IDE and Komodo use Scintilla, which is a freely available syntax highlighting text component. Every programmer's editor should be using that.

Other IDEs

I've used WSAD (Websphere Application Developer), Eclipse (same difference), and Visual Studio for extended periods of time. So I actually did use them every day for 8 hours a day, day after day. Which is good because I wouldn't have used them or taken them seriously otherwise. When you have deadlines you'll find your flexible brain is smart enough to figure out how to get the most out of anything. I can crank out code in these monstrosities - so I know it can be done.

All the hassle of using a big name IDE as opposed to Emacs only adds up to 20 or 30 lost hours of work a month (although that's not counting all the time it took to learn it in the first place) - and maybe a cramped mouse hand if I'm not diligent. So it is not impossible to work with them.

However, I can also count on any IDE costing me at least one lost day of work in every 30 with some inane configuration problem. And whenever I spend more than an hour pecking around in menu system trying to find something that should be set in a text file - it really, really frustrates me. I get angry and I start kicking things, and I want a real text editor again.

What's good about Visual Studio?

Eclipse is better for text manipulation and pure keyboard navigation than Visual Studio. The thing that Microsoft™ got right is debugging. Debugging is an easy and natural thing in Visual Studio™. In Eclipse it is a process that involves gnashing of teeth and opening up a new "Perspective" and slowing your computer down to a crawl.

The good things Eclipse gives you are refactoring, error highlighting, coordination with a built in web server - and various "Go to Definition" type functionality. But I don't like automatic error highlighting, and find the built in web server just makes for developers that have no idea how a web server works.

And the various structural code navigation features are handy, but nothing I can't do with ctags. And if I use ctags I have a process in place that will work for the every language I work with the same way. Consistency is good.

Automated refactoring, on the other hand, is certainly a quality that is better in Eclipse than Visual Studio. But the argument people make is that it is most necessary when you are working with 500,000 lines-o-code. But if you are working with that much code, Eclipse is going to die a slow death.

A good query-replace works good enough. Sorry. I think everyones obsession with refactoring is a classic "looking at the finger that is pointing at the moon" problem. The book Refactoring was showing us all how to think about code better. Not a series of patterns that needed be to automated.

The main reason I'm willing to keep trying something other than Emacs is for a better debugger. I keep hoping for Emacs + the Visual Studio debugger - or the Wing IDE debugger for that matter.

Copying Visual Studio

All the modern IDEs have one thing in common. This is my personal and incorrect opinion, but I'll say it anyway. They are trying to copy Visual Studio. They are trying to copy the debugger, the properties window, and the drag and drop GUI builder. In fact it's still Visual Basic emulation - 10 years later.

Just copy the Debugger

The most useful thing to replicate from Visual Studio I'd say is the debugger, because it is good. I have to admit. But I don't think replicating it exactly is necessarily the right idea. Because the main thing that strikes me about the debugger in Visual Studio is that is works fast enough that you can ignore all the fluff. Whereas a lot of people are trying to replicate the fluff - I think they should be replicating the speed.

One problem with most debuggers is they are set up to give you a host of unasked for and unnecessary information - and that crunch time is what slows everything down - and requires mouse navigation. I do not need the entire call stack and every known variable every time I debug. Sometimes I just need to know one very specific thing. That's why a command line debugger isn't so bad.

Command Line Debugger is Actually Okay

Look at the documentation of commands for PyDB. Everything is there. Step. Next. Examine. Restart. That's all you need and all that debugging is. Debugging a program is just the equivalent of saying "run this program - then stop it right here - and let me poke around. I may or may not continue running it". A freeze-frame.

In theory, you could write the commands you would issue to a command line debugger out into a file and send that file to someone else who could in turn run the commands and go to the exact same spot of code with the exact same variables and look at the exact same thing you did. That's an unforeseen use. You can't do something like that with a GUI debugger. Because it has not allowed for unforeseen use.

But I've never actually done that to tell you the truth. So it's probably not very practical. A unit test serves the same purpose. And like I said earlier, using a command line debugger feels like sending commands to an orbiting spacecraft.

Conclusion

So I'm looking for a compromise. The main weak point with Emacs is the debugger, and the strong points of Wing IDE and Komodo are the debuggers - so as they catch up in other respects, Emacs may be in trouble someday. But I still vote for Emacs as of now. Besides it's free.

Postscript

So far, every traditional IT job I've ever had (as opposed to just a job that involves programming) has insisted I use an IDE. All of those jobs did not suit me. Maybe there is a connection. My new resolve is to never take a job where I'm not allowed to use Emacs.