Make, for example, can be started with the Emacs command ESC-x compile followed by an Enter. This command will run make(1) in the current directory, capturing the output in an Emacs buffer.

This by itself wouldn't be very useful. But Emacs's make mode knows about the error message format (featuring a source file and line number) emitted by Unix C compilers and many other tools.

If anything run by make issues error messages, the command Ctl-X ` (control-X-backquote) will try to parse them and take you to each error location in turn, popping open a window on the appropriate file and taking the cursor to the error line.^[138]

This makes it extremely easy to step through an entire build, fixing any syntax that has been broken since the last compile.

For catching runtime errors, Emacs offers similar integration with your symbolic debugger — that is, you can use an Emacs mode to set breakpoints in your programs and examine their runtime state. You run the debugger by sending it commands through an Emacs window. Whenever the debugger stops on a breakpoint, the message the debugger ships back about the source location is parsed and used to pop up a window on the source around the breakpoint.

Emacs's Grand Unified Debugger mode supports all the major C debuggers: gdb(1), sdb(1), dbx(1), and xdb(1). It also supports Perl symbolic debugging using the perldb module, and the standard debuggers for both Java and Python. Facilities built into Emacs Lisp itself support interactive debugging of Emacs Lisp code.

At time of writing (mid-2003) there is not yet support for Tcl debugging from within Emacs. The design of Tcl is such that it seems unlikely to be added.

Once you've corrected your program's syntax and fixed its runtime bugs, you may want to save the changes into a version-controlled archive. If you've only tried running version-control tools from the shell, it's hard to blame you for sloughing off this important step. Who wants to have to remember to run checkout/checkin commands around every edit operation?

Fortunately, Emacs offers help here too. Code built into Emacs implements a simple-to-use front end for SCCS, RCS, CVS, or Subversion. The single command Ctl-x v v tries to deduce the next logical version-control operation to do on the file you are visiting. The operations this includes are registering a file, checking out and locking it, and checking it back in (accepting a change comment in a pop-up buffer).^[139]

Emacs also helps you view the change history of version-controlled files, and helps you back out changes you don't want. It makes it easy to apply version-control operations to whole sets or project directory trees of files. In general, it does a pretty good job of making version-control operations painless.

The implications of these features are larger than you might guess before you've gotten used to it. You'll find, once you get used to fast and easy version control, that it's extremely liberating. Because you know you can always revert to a known-good state, you'll find you feel more free to develop in a fluid and exploratory way, trying lots of changes out to see their effects.

Surprise...this is perhaps the only phase of the development cycle in which Emacs front-ending does not offer substantial help. Profiling is an intrinsically batchy operation — instrument your program, run it, view the statistics, speed-tune the code with an editor, repeat. There isn't much room for Emacs leverage in the profiling-specific parts of this cycle.

Nevertheless, there's a good tutorial reason for us to think about Emacs and profiling. If you found yourself analyzing a lot of profiling reports, it might pay you to write a mode in which a mouse click or keystroke on a profile report line visited the source of the relevant function. This actually would be fairly easy to do using the Emacs ‘tags’ code. In fact, by the time you read this, some other reader may already have written such a mode and contributed it to the public Emacs code base.

The real point here is again a philosophical one. Don't drudge — drudging wastes your time and productivity! If you find yourself spending a lot of time on the low-level mechanical parts of development, step back. Apply the Unix philosophy. Use your toolkit to automate or semi-automate the task.

Then give back something in return for all you've inherited, by posting your solution as open-source software to the Internet. Help liberate your fellow programmers from drudgery, too.

Earlier in this chapter we asserted that Emacs can give you capabilities resembling those of a conventional integrated development environment, only better. By now you should have enough facts in hand to see how that can be true. You can run entire development projects from inside Emacs, driving the low-level mechanics with a few keystrokes and saving yourself the mental effort and disruption of constantly switching contexts.

The Emacs-enabled development style trades away some capabilities of advanced IDEs, like graphical views of program structure. But those are frills. What Emacs gives you in return is flexibility and control. You're not limited by the imagination of the IDE designer: you can tweak, customize, and add task-related intelligence using Emacs Lisp. Also, Emacs is better at supporting mixed-language development than conventional IDEs.

Finally, you're not limited to accepting what one small group of IDE developers sees fit to support. By keeping an eye on the open-source community, you can benefit from the work of thousands of your peers, Emacs-using developers facing challenges much like yours. This is much more effective — and much more fun.