Emacs: Friend or Foe?
If you're like me, you find Emacs somewhat intimidating. Well, if you're like me, you've been an exclusive vi user for years, and have always wanted to start using Emacs, but have had trouble doing so. Each time you try to switch over, you find yourself pressing <esc> after every third sentence, which (in Emacs) produces some random, and usually undesirable, result. Once, I was thrown into the infamous “Doctor” mode, which is a simple AI program emulating a psychiatrist. There, I spent a good ten minutes telling Emacs what I thought of it. (The response was, "Perhaps you could try to be less abusive.")
Using one of Emacs' vi-emulation modes isn't of much help, either; none of them seem to handle even basic vi commands appropriately. And if you tend to use less-well-known vi features, you're simply out of luck. (Ever try changing the window size with nnnzwww^? I didn't think so.)
As impossible as it may seem, you can find a place for Emacs in your everyday life. If you have the diskspace and memory (a far-from-negligible detail), I strongly suggest looking into Emacs; it can make your life easier, even if you think that you're perfectly content with vi.
Whether you're accustomed to vi or not, however, the default Emacs configuration on many systems is, well, less than adequate. While many users learn to live with Emacs “out of the box”, I've never been content with that approach. Instead, you can get Emacs to do just about whatever you want it to do. So, let's take a look at some customizations that I've found particularly useful.
All of the customizations discussed here involve editing the Emacs configuration file, which is ~/.emacs by default. This file is written in Emacs LISP (Elisp), which is the internal LISP engine that Emacs uses for nearly everything. For example, keystrokes map to Emacs LISP commands. You can modify the command to be executed for each key sequence, and even write your own Elisp functions to bind to keys.
If you're not a LISP programmer, never fear. Most of the LISP forms described here are quite simple and don't require a degree in artificial intelligence to comprehend.
I do assume that you have at least tried to use Emacs, and know how to get into and out of it, are familiar with the Info documentation system, and so on. If not, fire up Emacs and type Ctrl-h (C-h) followed by t, which will drop you into a tutorial. (From there, you're on your own.) The following customizations work under Emacs 19.24. By the time you read this article, there will more than likely be a newer version available, for which certain things may have changed.
Before we can customize Emacs, we need a customization file. By default this is .emacs in your home directory. (Later, we're going to move the contents of .emacs to another file, so buckle your seatbelt.)
Our first task is to rebind several keys to perform more reasonable actions. Admittedly, several of these key bindings are vi-oriented, but should make sense nonetheless. First of all, I like to page back and forth through the document with C-f and C-b, as in vi. In order to rebind these keys, we'd include these lines in our .emacs file:
; Modify meaning of C-f and C-b (global-set-key "\C-f" 'scroll-up) (global-set-key "\C-b" 'scroll-down)
As you can see, comments in Elisp begin with a semicolon and extend to the end of the line. Here, we invoke the function global-set-key twice; once for C-f and again for C-b. In LISP, expressions are parenthesized. The first item in each list is the name of the function to call, and it is followed by any arguments. The first argument to global-set-key is a string constant, representing the key sequence to bind. The second argument is the name of the Emacs LISP function to bind it to. The function name is single-quoted in order to refer to the function name itself, not the function that it points to.
One question remains: How did we know that scroll-up and scroll-down referred to the Emacs functions to scroll pagewise through the document? Other than reading the documentation, you could find this out by using the Emacs function describe-key (which you can invoke with C-h k). Calling this function and following it with a key sequence will tell you the Emacs function name that the key sequence maps to. If you knew that the Emacs keys C-v and M-v (Meta-v, where “meta” is usually the <esc> key) scrolled back and forth through the document, you could use C-h k to determine the function names for these keys. For example, the sequence C-h k C-v will display the function name bound to C-v.
Here are a few more key rebindings that I use often:
(global-set-key "\C-v" 'end-of-buffer) (global-set-key "\M-v" 'beginning-of-buffer) (global-set-key "\C-p" 'yank) (global-set-key "\C-u" 'undo) (global-set-key "\C-r" 'overwrite-mode)
The first two commands rebind C-v and M-v (which previously scrolled by pages) to move to the beginning and end of the buffer, respectively. The third causes C-p to yank the previously deleted or copied region of text, and the fourth causes C-u to execute the undo command. (I tend to use the Emacs' undo feature quite a bit, and find C-x u or C-_ too cumbersome.) The last command causes C-r to toggle overwrite mode.
There are some caveats associated with rebinding keys in this manner. For one thing, it destroys the previous definition of the key. In many cases, this is fine; as long as you didn't use the key as previously defined. However, the last of the above commands rebinds C-r, which is used to invoke a backwards incremental search; a very useful feature. Before rebinding a key you should be sure that its previous definition doesn't mean much to you.
Now, what about bindings involving multiple keys? For example, I like to use the key sequence C-d C-d to delete a line (somewhat like its vi counterpart), and C-d g to delete text from point to the end of the buffer. The second argument to global-set-key can include multiple keys, but the problem is that C-d already has a meaning. We want to use C-d as a “prefix” key for the commands C-d C-d and C-d g, so first we have to unbind C-d. Here's what we do:
; Various keys for nuking text (global-unset-key "\C-d") (global-set-key "\C-d g" 'my-nuke-to-end) (global-set-key "\C-d\C-d" 'my-nuke-line)
We simply use global-unset-key to unbind C-d, and then bind new meanings to C-d g and C-d C-d. However, these functions are bound to the mysterious functions my-nuke-to-end, and my-nuke-line, which the astute among you will notice aren't standard Emacs functions. We have to define them.
Defining an Emacs LISP function is rather simple. Of course, Emacs functions can be quite powerful and complex, but in this case we're going to use the function to call a short sequence of other functions, which isn't so frightening. In general, if you need a key binding to call several functions in sequence, you must define a new function to wrap the sequence in.
Here is the definition of my-nuke-to-end, which should be placed above the corresponding call to global-set-key, which uses it, in the .emacs file.
(defun my-nuke-to-end () "Nuke text from here to end of buffer." (interactive "*") (kill-region (point) (point-max)))
The defun function takes as arguments the function name to define, a list of arguments (which, here, is empty), followed by the body of the function. Note that the first line of the body is a string constant, which is a short description of the function. This string is displayed when describe-key or describe-function is used to display information about my-nuke-to-end.
The second line of the body is a call to the interactive function. This is required for functions that are bound to keys. It simply tells Emacs how to execute the function interactively (that is, when called from a key sequence). The argument to interactive, “*”, indicates that the function should not be executed within a read-only buffer. Check out the documentation for interactive if you want the gritty details. (See the sidebar “Getting the Emacs LISP Manual” for information on obtaining this documentation.)
The last line of the body uses the Emacs internal function kill-region to delete a region of text. The two functions point and point-max return the current location of point, and the position of the end of the buffer, respectively. kill-region deletes the text between these two locations.
The definition for my-nuke-line is somewhat more involved, because there is no single Emacs function that this operation maps to. Here it is:
(defun my-nuke-line (arg) "Nuke a line." (interactive "*p") (beginning-of-line nil) (kill-line arg) (if (= (point) (point-max)) (progn (forward-line -1) (end-of-line nil) (kill-line arg) (beginning-of-line nil))))
First of all, we see that this function now takes an argument, which we have called arg. Many Emacs key functions take a single numeric argument, which you can specify by prefixing the key with C-u, followed by a number. (That is, unless you've rebound C-u, as we have.) This numeric argument changes the behavior of certain functions. Here, arg is passed along to kill-line, used on lines 4 and 9 of the function body.
my-nuke-line is essentially a wrapper for kill-line, but takes care of a special case for the last line in the buffer. In this case, we want to delete the newline before the last line, which causes the last line to be clipped out altogether (otherwise, Emacs deletes the line, but leaves a blank one in its place). After interactive is called (with the “*p” argument, which causes arg to be converted to a number), beginning-of-line moves point to (surprise!) the beginning of the line. kill-line is then invoked. Note that kill-line only kills text from point to the end of the line; not the entire line.
Next, we compare the cursor position (point) with the end-of-buffer position (point-max). If they are equal, then we are trying to delete the last line of the buffer, and want to kill the previous terminating newline. We move back a line (using forward-line with an argument of -1), move to the end of that line, kill the rest of the line (which consists only of the terminating newline), and move back to the beginning of the line. All of this results in the last line of the buffer being deleted.
I'm sure that there are Emacs gurus out there that can find much better ways to accomplish the same thing; please bear with me. I've been brainwashed by vi. One of Emacs' better features is that there are many ways to modify its behavior.
Now that you've had a crash course in Emacs LISP programming, let's move on to something more practical. Once you start customizing Emacs, you'll notice that your .emacs file gets to be quite large, and may take a while to load. You may be aware that Emacs allows you to byte-compile LISP source files for faster loading, so let's utilize that feature on our .emacs configuration file.
The first step is to create a directory for your personal Emacs LISP files to reside. At first this directory will contain only one file; namely, your initial configuration file; but later in life you may wish to write separate Elisp files. I use the directory emacs in my home directory for this purpose.
Next, copy your .emacs file to this directory, and rename it to something like startup.el.
Now, we replace the contents of .emacs with a short bit of code that byte-compiles emacs/startup.el and loads it. However, we only want to byte-compile startup.el if it is newer than its compiled counterpart, startup.elc. Here's the trick:
(defun byte-compile-if-newer-and-load (file) "Byte compile file.el if newer than file.elc" (if (file-newer-than-file-p (concat file ".el") (concat file ".elc")) (byte-compile-file (concat file ".el"))) (load file)) (byte-compile-if-newer-and-load "~/emacs/startup")
This is blatantly obvious, I'm sure, but by way of explanation: this bit of code defines a new function, byte-compile-if-newer-and-load (keeping in line with the Emacs' affinity for verbose function names), and executes it on ~/emacs/startup.el. We have now moved all of the Emacs configuration code to startup.el which is byte-compiled when necessary.
Emacs and the X Window System are two good things that are great together. In fact, my primary motivation for starting to use Emacs for the four thousandth time was to have an editor that incorporated many of the nice features of X, such as mouse-based region cut-and-paste, and so forth. Emacs 19 has support for many useful X-based features, some of which I'll introduce here.
The first thing that you might want to do when using Emacs under X is customize the colors. I'm no fan of black and white; and in fact, I prefer lighter fonts on a dark background. While you can customize Emacs' X-specific attributes using the X resource database (e.g., by editing ~/.Xdefaults), this isn't quite flexible enough. Instead, we can use Emacs internal functions such as set-foreground-color.
For example, in your startup.el file, you might include:
(set-foreground-color "white") (set-background-color "dimgray") (set-cursor-color "red")
which will set these colors appropriately.
Emacs also provides support for faces, used most commonly within font-lock-mode. In this mode, text in the current buffer is “fontified” so that, for example, C source comments appear in one font face, and C function names in another. Several of Emacs' major modes have support for font lock, including C mode, Info, Emacs-Lisp mode, and so on. Each mode has different rules for determining how text is fontified.
For simplicity, I employ faces of the same font, but which use different colors. For example, I set the “bold” face to light blue, and “bold-italic” to a sick shade of green. Each major mode has a different use for each face; for instance, within Info, the bold face is used to highlight node names, and within C mode, the bold-italic face is used for function names.
The Emacs functions set-face-foreground and set-face-background are used to set the colors corresponding to each face. For a list of available faces and their current display parameters, use the command M-x list-faces-display.
For example, I use the following commands in startup.el to configure faces:
(set-face-foreground 'bold "lightblue") (set-face-foreground 'bold-italic "olivedrab2") (set-face-foreground 'italic "lightsteelblue") (set-face-foreground 'modeline "white") (set-face-background 'modeline "black") (set-face-background 'highlight "blue") (set-face-underline-p 'bold nil) (set-face-underline-p 'underline nil)
The modeline face (which is referred to in the Emacs documentation as mode-line, for some reason) is used for the mode line and menu bar. Also, the function set-face-underline-p can be used to specify whether a particular face should be underlined. In this case I turn off underlining for the faces bold and underline. (A non-underlined underline face? Hey, this is Emacs. Anything is possible.)
In order to use all of these wonderful faces, you'll need to turn on font-lock-mode. You may also wish to enable transient-mark-mode, which causes the current region (text between point and mark) to be highlighted using the region face. The following commands will enable this.
(transient-mark-mode 1) (font-lock-mode 1)
One problem with the above configuration is that font-lock-mode is not automatically enabled for each major mode. Including the font-lock-mode command in your startup.el file will enable this mode when Emacs first begins, but not for each new buffer that you create. In general, this is true for any Emacs minor mode; you must turn on the minor modes whenever you enter a new major mode.
What we want to do is have the font-lock-mode command be executed whenever we enter certain modes, such as C mode or Emacs LISP mode. Happily, Emacs provides “hooks” which allow you to execute functions when certain events occur.
Let's turn on several minor modes whenever we enter C mode, Emacs LISP mode, or Text mode:
(defun my-enable-minor-modes () "Enables several minor modes." (interactive "") (transient-mark-mode 1) (font-lock-mode 1)) (add-hook 'c-mode-hook 'my-enable-minor-modes) (add-hook 'emacs-lisp-mode-hook 'my-enable-minor-modes) (add-hook 'text-mode-hook 'my-enable-minor-modes)
Now you should find that upon entering any of these major modes, the corresponding minor modes are enabled as well. In general, each major mode has an entry hook, named modename-hook.
Instead of using global-set-key to define key bindings for all major modes, we can use define-key to set bindings for particular modes. In this way we can specify the behavior of certain keys based on the major mode that you happen to be in.
For example, I prefer that the return key indent the next line of text relative to the one above it (if the previous line is indented five spaces, the next line should be as well). To enable this feature in C mode, Emacs LISP mode, and Indented Text Mode, use the commands:
(define-key indented-text-mode-map "\C-m" 'newline-and-indent) (define-key emacs-lisp-mode-map "\C-m" 'newline-and-indent) (define-key c-mode-map "\C-m" 'newline-and-indent)
Each mode has a modename-map associated with it, which specifies the key bindings for that mode. As you may have guessed, newline-and-indent is the Emacs function which does a newline followed by a relative indent.
When editing files, Emacs usually determines the mode to use from the filename extension. If I were to edit a new file called clunker.c, C mode would be used as the default. However, when unable to make a decision, Emacs uses Fundamental mode. I prefer to use Indented Text mode instead, which is enabled with the command:
(setq default-major-mode 'indented-text-mode)
Local key bindings can be used for more interesting tasks than those demonstrated above. For example, the command M-x compile will issue the command make -k (by default) in the current directory, thereby compiling whatever code you may have been working on. Output and error messages from the make command are displayed in a separate window. You can select error messages from the compilation buffer, in which case Emacs will automatically open up the corresponding source file and jump to the line containing the error. In all, this makes editing, compiling, and debugging programs much more efficient; you can do literally everything within Emacs.
In order to automate the process of saving the current source file and issuing make, we can bind the key sequence C-c C-c to a new function; let's call it my-save-and-compile. The code looks like this:
(defun my-save-and-compile () "Save current buffer and issue compile." (interactive "") (save-buffer 0) (compile "make -k")) (define-key c-mode-map "\C-c\C-c" 'my-save-and-compile)
The save-buffer command is used to save the current source file, and compile is issued with the command make -k. Now, with two simple keystokes you can fire your source file off to the compiler, and wait for the error messages to roll in. Without the my-save-and-compile function, you have to save the source file (using C-x C-s) and issue M-x compile by hand.
Of course, to use this feature you'll have to create a Makefile in the directory where your source files live. (The make command is issued in the directory containing the source file in question.) Creating Makefiles is another issue altogether. A future issue of Linux Journal will discuss this subject, but in the meantime there are several sources of information about make. The book Managing Projects with make from O'Reilly and Associates is a good place to start, as is the GNU make Manual, which covers the version of make available on Linux systems.
Also note that compile will first prompt you to save any modified buffers. If you modify only one buffer at a time, my-save-and-compile saves it for you. We could have my-save-and-compile save all modified buffers, but you may not want that to happen automatically behind your back.
As we mentioned, the compile function will open a new window containing messages from the make command. From this buffer, you can select error messages for Emacs to automatically jump to, allowing you to fix the problem and move on. If you are running Emacs under X, clicking on an error message with the second mouse button will take you to the line containing the error. Otherwise, you can move point to the error message (in the compilation buffer), and use C-c C-c (don't be confused by the multiple meanings of this key sequence). Alternately, you can use the function next-error to visit the next error message. In my startup.el I have this function bound to M-n in C mode (which, by now, you should know how to do).
There are several small items that you might want to configure to depart from Emacs' default behavior. I'm going to list the code for these briefly below; none of them involve new concepts other than those discussed above. The comments should describe these customizations adequately.
;; Allow M-j, M-k, M-h, M-l to move cursor, ;; similar to vi. (global-set-key "\M-j" 'next-line) (global-set-key "\M-k" 'previous-line) (global-set-key "\M-h" 'backward-char) (global-set-key "\M-l" 'forward-char) ;; Commonly used buffer commands, requiring ;; less use of CTRL ;; (For the ergonomically-minded.) (global-set-key "\C-xf" 'find-file) (global-set-key "\C-xs" 'save-buffer) ;; Open a line below the current one; as in "o" in vi (defun my-open-line () (interactive "*") (end-of-line nil) (insert ?\n)) (global-set-key "\C-o" 'my-open-line) ;; Make the current buffer the only visible one, ;; and recenter it. (defun my-recenter-frame () (interactive "") (delete-other-windows) (recenter)) (global-set-key "\C-l 'my-recenter-frame) ;; Save all buffers and kill Emacs, without prompting (defun my-save-buffers-kill-emacs (arg) (interactive "P") (save-buffers-kill-emacs t)) (global-set-key "\C-x\C-c" 'my-save-buffers-kill-emacs) ;; Preserve original save-buffers-kill-emacs, ;; in case we don't want ;; to save what we were doing (global-set-key "\C-x\C-x" 'save-buffers-kill-emacs) ;; Real Programmers don't use backup files (setq make-backup-files 'nil) ;; But Real Programmers do use RCS. Includes ;; rcsid[] definition in a C source file (defun my-c-insert-rcsid () (interactive "*") (insert "static char rcsid[] = \"@(#)$Header$\";")) (define-key c-mode-map "\C-c\C-x" 'my-c-insert-rcsid) ;; Finally, prevent next-line command from adding ;; newlines at the ;; end of the document. Instead, ring the bell when ;; at the end of ;; the buffer. (setq next-line-add-newlines 'nil)
I hope that this whirlwind tour through the world of Emacs customization has been useful, or, at least entertaining. I've found many of the above modifications to be invaluable. Remember the old saying: Have Elisp, will travel.
That being said, it's back to vi for a while.
Matt Welsh (mdw@sunsite.unc.edu) is a programmer at the Cornell University Robotics and Vision Laboratory. He spends his free time homebrewing virtual beer and playing the blues.