What I Wish I'd Known About Emacs

The admission of emacs into the editor war is something of a misrepresentation. That emacs can be used as a text editor is incidental to its nature as a computing environment.

This is the first obstacle that an emacs newbie has to get over: You are not in a program like notepad++ or slickedit and the sooner you get that misconception out of your head the sooner you'll appreciate emacs for what it is.

Though it may offend some GNU zealots out there but the closest commoditized software equivalent to emacs that I can think of is actually MS Office (please withhold flames until you've finished).

That isn't to say that emacs is an office suite (tho' it could be) but that the technical underbelly of Office is similar, in a vague, spiritual sense, to the technical underbelly of emacs.

Office, at its core, is a computing interface. This is not the same as a User Interface, which gives humans buttons to click and things to type into. A computing interface is a means by-which programs can communicate with each other.

The two important components to MS Office are the Visual Basic interpreter and the Component Object Model. None of the programs that people think of as being the Office suite are natively-compiled programs. Instead, each of the applications (Word, Powerpoint, Excel, Outlook) are Visual Basic programs that get run by the VB interpreter that is MS Office. What makes Office especially handy to people is that it can share information freely between each of the applications in the suite as well as with the rest of the operating system through COM.

Emacs is a similar beast. Emacs is a LISP interpreter. Most of the editing (and other) features are written in emacs' native LISP language. Because emacs is a Turing complete system, it can modify its own state. This ability to self-modify leads to handy editing capabilities and interoperability of all the components of emacs in a similar way you might get from MS Office. Emacs is also accustomed to interacting with the rest of the OS through Unix pipes.

Thinking of emacs as a self-modifying computing system will put you at a great advantage over people coming from the world of vi(m). Unlike the more editor-like members of the text editor family, emacs makes no effort to hide its technical underbelly – but rather, encourages and greatly rewards those who embrace it.

It has been said that emacs is "highly customizable" but that's something of an understatement as emacs is every bit as capable as any other programmable system.

If anything about emacs displeases the user he is free to change it! The emacs wiki and stack overflow are both ripe with simple tweaks to better tune emacs' behavior. Any tweak that isn't already available is usually simple to write. When I didn't know how, the folks on Stack Overflow were quick to provide simple solutions for me.

A user need not be comfortable with programming in LISP (or any language) in order to be able to implement changes. For the most part, simply copying text into the .emacs file is all that's required to get additional features.

Customizations live in a .emacs file. That'll be ~/.emacs if for those in a Unix-like system or C:\Users\<you>\.emacs for Windows Vista or newer. Customizations placed in the .emacs file won't require a restart in order to apply; simply evaluate the buffer.

Some editors offer an API or hooks that permit third-party add-ons to be run on the editor. This method of enhancing or customizing a text editor application is usually very code-heavy, requires more debugging, and requires a lot of knowledge before you begin.

Emacs simplifies the process, removing many of the unnecessary steps and technical complications by simply allowing the user to write customizations through the same mechanism that the rest of the emacs environment runs in. No special hooks, no API's, no indirection separates the user from the desired goals.

There is a bit of emacs terminology that seemed backwards to me when I first started using it. It may save you a bit of confusion to know the following things:

1. "yank" actually means "paste" in emacs. This is especially confusing for vi users who assume "yank" means to copy.
2. "kill" has two meanings: The first, most common, is synonymous with "cut" in the standard clipboard sense. But if you "kill" a buffer, you're not actually cutting all the contents of the buffer into the "kill ring" but deleting the buffer from memory and abandoning any text within it (close without save).
3. "kill ring" is synonymous with "clipboard." Emacs retains its own kill ring separate from your system's clipboard. The graphical emacs is aware of the system clipboard and can put data into that as well.
4. "point" is the cursor. So if somebody says "kill thing at point" they probably mean cut the character that the cursor is over.
5. "window" isn't a reference to GUI windows. Because emacs predates graphical user interfaces, they used the term to describe divisions of the screen that appear more like iframes in a browser or panes dividing what you'd think of as a GUI window.
6. "frame" is a GUI window. Just so you stay confused; a "frame" in graphical emacs is synonymous with actual GUI windows as rendered by your X Server or Windows.
7. "M-" means "meta" means "Alt" and "C-" means the "control" key. When emacs describes shortcut keys, they do so in the form of a capital letter, a dash, and then another lower case letter or word. This denotes that you hold the key associated with the big letter and then the key described in lower case at the same time.
8. Meta may not be alt. On older Unix systems, the key for Meta is actually Escape. On some systems, this may still be the default config. If Alt doesn't appear to do what it should, try using ESC instead.
9. "C-g" is the "cancel" key. In most cases where your instincts would lead you to press ESC, CTRL+g is the correct choice. It aborts active functions and clears the input state.
10. "Key chords" evokes a misleading musical idea. A key chord is a sequence of keys that are hit in succession, not a series of keys pressed together.
11. Spaces denote key chords. If a keyboard shortcut is shown in the form of, say "C-x C-s" you are looking at two separate key combos: CTRL+x then CTRL+s. This is the default key chord for saving a file. To evoke this key chord, hit CTRL+x and then hit CTRL+s. You do not need to let go of CTRL at any point but you should not hold X and S at the same time.
12. "RET" means "return" or the "enter" key.
13. "Region" is the area of selected text.

Understanding the short-hand could've saved me a couple of hours.

In the world of 3D animation, modeling software will show 3D space from multiple angles simultaneously so the user can get the big picture of the meshes, the lighting, and all that's going on at once.

Emacs is similar in that you can edit multiple streams of text concurrently with multiple windows showing you different parts of the same text. This helps you get a big picture.

Many text editors also let you have multiple documents open at once: Maybe dividing them into separate tabs or sub-windows in the editor's window space.

The emacs equivalent of editor tabs are called "buffers." Each buffer retains the text and other relevant information associated with it (such as highlighting and auto-indenting preferences unique to that buffer's content).

Buffers are also used for more than just keeping data associated with a file on disk. Any transient or temporary data can be shown in a buffer. If you run the emacs calculator application, it creates a buffer containing the stack of the calculator and another buffer to retain your history so you can review calculator activity. If you run emacs in Python mode, a Python shell is opened in the background and it reports errors and other messages to a unique logging buffer.

Some buffers are read-only. Data can also pass freely between buffers without having to use the kill ring (the clipboard). This means that, if you ever wanted to have multiple simultaneous clipboards, you could easily accomplish this with emacs buffers and a couple key bindings.

There is one special buffer called the minibuffer that is handy for evoking various functions available in the emacs environment (that is any function that emacs can run, you can run from the minibuffer).

Almost all of the functionality of emacs is found in LISP functions somewhere in the source code. Very few functions are compiled into the binary itself and even those compiled functions are still visible to the LISP interpreter.

This means that all emacs functionality is accessible to the user by evoking the function directly. Any key chords can also be arbitrarily bound to evoking such functions. The default key chords are set up in the source that emacs interprets when it starts up.

Functions may also be bound to arbitrarily-defined menu items. The common "File" and "Edit" drop menus in emacs do nothing more than call functions found in LISP files somewhere in emacs' share directory.

When the emacs info pages (the self-generated documentation of emacs) or the emacs wiki or users in online forums offer instruction on how to activate certain functions, the most common way they do so is by showing key chord notation like so:

C-h h

Means "hit CTRL+h and then just h" and the related function will be evoked.

The second most common way that documentation and the community will use to expose functionality is to give the specific function name associated with that functionality and explain the exact keyrpesses required to evoke it.

M-x find-file RET ~/.emacs

Here the user is advised to hit ALT+x then type "find-file" into the minibuffer followed by the Enter key. This will start the find-file function which will then prompt the user for the path of a file to open. By typing "~/.emacs" into that prompt, emacs will open the .emacs configuration file for editing. The default key chord bound to find-file is C-x C-f.

Opening menu items is rarely necessary but can be accomplished by hitting F10 (the equivalent to ALT+F in Windows or GTK environments).

The emacs environment has also been described as "self-documenting" because even if the functions of emacs are not explicitly documented, emacs is happy to show the user exactly where the code of the function resides so he can discover exactly how it works.

Among the most handy functions available to the user are…

1. describe-function
2. describe-key
3. describe-variable

To discover the things that emacs already knows how to describe, simply go:

M-x describe TAB

By hitting tab, it will open a new window and buffer listing all the functions that begin with the word "describe."

If the function "find-file" is a mystery, simply go:

M-x describe-function RET find-file RET

And emacs will open a new window with a buffer containing everything it knows about the function named "find-file" – including a link to the source code that it is running.

You could modify find-file right there in emacs and change the behavior of that function (and, by extension, the whole editor) if you wanted.

With tab completion and the ability to describe all the functions, the variables that keep settings, and all the key bindings in the environment, there is very little about emacs that one can't discover on one's own. The whole system is eager to help the user understand it at a very intimate level.

Even if you're not using emacs in a Unix environment, it helps to know that that is where emacs is from. Emacs will therefore behave in ways that are very Unix-like no matter what you do to it.

Emacs assumes that it can run sub-processes (which is why it never caught-on in the single-tasking DOS or even Win9x world) and many of the useful things you can do with it require that.

Programs run by emacs will often have their output stored in a unique buffer. If you open a man page in emacs, it shows up as a formatted buffer. PDF files, when viewed, will appear in special PDF viewing buffers that will have special interface options unique to viewing PDF's.

Many abilities of emacs are derived from other programs which it executes as sub-processes.

This does mean that some emacs features can have a sprawling set of dependencies. If you work in an environment without good package management, this can lead to dependency hell or living without some features. These problems can be mitigated by using features developed natively in emacs.

The up side is that emacs becomes extensible without having to write extensions specifically for that environment. Any flexibly-designed software will be able to help emacs process data and keep the results in an editable buffer. Any emacs lisp can also manipulate those results, co-opting other programs to vastly improve the functionality with minimal programming effort.

In the emacs world, people make heavy use of "modes." There are "Major Modes" that set the overall tone of the editor and there are "minor modes" which modify the current major mode to be more useful in specific ways.

The mode determines what keyboard shortcuts are available, how the text will tend to be formatted and displayed, what menus will appear in the menu bar, and so forth.

For editing source code, there are modes that define syntax highlighting, code folding, debugger hooks, source control integration, and other typical IDE-like features.

For editing text documents, there are LaTeX mode, HTML mode and the glorious gran-daddy of them all; org mode (the emacs mode used to create this web page).

For browsing the web, there's a browser mode. For instant messaging, there's stuff like jabber mode, and if you're bored by the total lack of geometric organizing going on in your face, the tour shows you how to play Tetris within an emacs buffer.

At first, using emacs without caring about LISP may work. Eventually, however, the lust to customize will drive the dedicated emacs user to learn to write quick little LISP snippets.

If the ocean of parenthesis intimidates you like it did this guy, it may help to understand that the entire reason emacs is awesome is because it is nothing but LISP.

LISP really is the reason I bothered giving emacs a chance; it was the only "IDE" that appeared to work for LISP programming. The purity, the cleanliness, and the correctness of the LISP family so attracted me that I was able to get over the few oddities of Emacs and really learn how to use it.

The virtues of LISP are better described by smarter people than me. (Yes, even in satire, it is praised.) I encourage you consult these works if you'd like to know more.

Emacs LISP is a variation of Common LISP. When hunting for documentation or help, be sure to specify "Emacs LISP" in your searches and questions because just "LISP" or even just "Common Lisp" will not be specific enough to get completely relevant information.

Use the scratch buffer often. It will allow editing and evaluating of source code on the fly; making the learning process much smoother than using something a little less fluid like a clisp shell.

It's true that there's a bit of a learning curve to emacs but my experience has been that it's totally worth it. I've tasted the great joy that is using emacs and I can't ever go back. Whether the system is Winderz or *nix, my computers are never seen without emacs.

If you've got more than a gig of memory, there really is no reason to hate emacs. Anybody who is willing to vest a single day in learning it may find themselves making a life-long friend!