I started using Emacs as a Linux IDE for a C++ project. At that moment I was also using IntelliJ IDEA for my personal Java project and wondered if I could have a comparable environment for C++ under Linux. My first try was to use Eclipse with CDT, but the experience was frustrating—CDT was slower than IDEA and in addition uncomfortable. The main reason for slowness was that CDT tried to do honest parsing of all our project and imported headers. Also it was failing miserably on some non-trivial parts due to high complexity of C++ itself.
Obviously, I needed something more lightweight, albeit not very primitive. By that time I already had had a positive experience of Windows development using only FAR’s built-in editor accompanied by some plugins, mainly Colorer and AutoCompletion. So, what about simple yet powerful programmer’s editors for Unix?
As everybody knows, there are lots of Unix-based editors that real programmers use, of which two can be viewed as IDEs: Emacs and Vim. I chose Emacs based on editors comparison done by Eric Raymond in “The Art of Unix programming” book and Steve Yegge’s evangelical posts on Emacs (see links in the last section). Mainly, I didn’t like the idea of interaction modes in Vim. As Jef Raskin said in his book “The Humane Interface”: “Modes are a significant source of errors, confusion, unnecessary restrictions, and complexity in interfaces”
This made my choice. So I grabbed “Learning GNU Emacs” and “GNU Emacs Manual” and dove into. It took just about an hour do learn the basic stuff. What amazed me first in Emacs is the idea of ubiquitous text buffers. Everything in Emacs is a text buffer. Thus, you can trivially transfer contents between them and use the same commands for editing and navigation. And the greatest benefit is that you can use search just everywhere. This is much more productive as opposed to “common” IDEs, where you have tree and list views, pop-up boxes, wizards and other stuff, all having different interaction behavior and abilities.
The Real Project
Having a confidence that Emacs is really useable and convenient, I started using it for a C++ project. Again, I was pleasantly surprised how good is Emacs at C++ coloring and indenting. Then, I attached etags, and this covered 90% of my auto-completion needs. Really, you don’t need to do a sophisticated parsing of source code in order to do good enough auto-completion.
So, using Emacs, I was able to do comfortable editing of C++ sources, Makefiles, SQL files, shell scripts and all other stuff that we used in the project. It was also easy to compile the project and navigate back to errors in the source code, do project-wide searching and perform non-trivial renamings with regexp search and replace. I was also talking to our version control system from Emacs. And all this by means of text buffers.
Extensions, Extensions, Extensions!
In parallel to my main project, I was also studying functional programming in Haskell and Scheme. Immediately I found excellent Emacs editor extensions for both (in Emacs, extensions are called “modes”, but they are not those evil interaction modes that are used in Vim) [Note: I’ve seen people complaining that Emacs’ modes are “evil modes” too, because your keyboard gestures are dependent on the current mode. That’s correct. But in Emacs mode is connected to a buffer, and you know in what buffer you are now. While in Vim, you switch mode, while staying in the same editing window. I find this confusing, and other people too.] This is what really amuses me in Emacs—name any programming language, version control system, feature of shell, whatever—and you always can find an extension to Emacs which allows you to interact with it. Really, “good ol’ C-x M-c M-butterfly…” in action!
For examples of Emacs extensions varieties, take a look at EmacsWiki. Thousands of people are publishing their extensions and short code snippets in Emacs Lisp that can solve any particular task. What’s really amazing is the wise Emacs internal architecture that allows those myriads of extensions to work together. Eclipse tries hard to achieve this, and the concept of plugin extension points is really similar to “hooks” in Emacs, but… But it’s almost impossible to write a useful Eclipse extension with just a few lines of Java code—too many low-level overhead. While in Emacs, you just write several lines of Emacs Lisp code and it works, and you can publish it, and everybody can just paste your code, and now it works for them, too (well, of course, I’m idealizing—but often this is true).
And these are really well-known and obvious extensions, for using Emacs as an editor. But I know people who literally live in Emacs. They read mail and news in it, organize their time and projects, surf the Web, write their blog posts, chat using IM extensions and use many-many more features including awesome Emacs’ interface for visually impaired people.
How Should I Start?
So, what can you read to study Emacs? You can begin with inspiring Steve’s articles: “My .emacs file”, “Tour de Babel” (here search for “Lisp”), “Effective Emacs”, “Saving Time”; read introductory pages of EmacsWiki; take a look at blogs dedicated to Emacs: minor emacs wizardry and M-x all-things-emacs; and don’t forget about built-in “info” system in Emacs itself.
And the last tip: as Emacs is very keyboard-intensive, the first thing that you need is a good cheatsheet for keyboard combos. Although I’ve seen many over the Web, the one that I like the most is that I made myself. Here it is.