Debra Cameron - Learning GNU Emacs, 3rd Edition

After you have created a private Lisp library and told Emacs where to find it, you're ready to load and use the Lisp packages that you've created. There are several ways of loading Lisp packages into Emacs. The first of these should be familiar from Chapter 10:

• Type M-x load-library Enteras a user command; see Chapter 10.

• Put the line (load " package-name ")within Lisp code. Putting a line like this into your .emacs file makes Emacs load the package whenever you start it.

• Invoke Emacs with the command-line option "-l package-name " . This action loads the package package-name .

• Put the line (autoload ' function " filename ")within Lisp code (typically in your .emacs file), as described in Chapter 10. This action causes Emacs to load the package when you execute the given function . [84]

After you have created your Lisp directory, you can make loading and running your Lisp files more efficient by byte-compiling them, or translating their code into byte code , a more compact, machine-readable form. Byte-compiling the Lisp file filename.el creates the byte code file filename.elc . Byte code files are typically 40 to 75 percent of the size of their non-byte-compiled counterparts.

Although byte-compiled files are more efficient, they are not strictly necessary. The load-librarycommand, when given the argument filename , first looks for a file called .elc . If that doesn't exist, it tries .el , that is, the non-byte-compiled version. If that doesn't exist, it finally tries just . Thus, you can byte-compile your .emacs file, which may result in faster startup if your .emacs is large.

You can byte-compile a single function in a buffer of Lisp code by placing your cursor anywhere in the function and typing M-x compile-defun. You can byte-compile an entire file of Lisp by invoking M-x byte-compile-file Enterand supplying the filename. If you omit the .el suffix, Emacs appends it and asks for confirmation. If you have changed the file but have not saved it, Emacs offers to save it first.

Then you will see an entertaining little display in the minibuffer as the byte-compiler does its work: the names of functions being compiled flash by. The byte-compiler creates a file with the same name as the original Lisp file but with cappended; thus, .el becomes .elc , and .emacs becomes .emacs.elc .

Finally, if you develop a directory with several Lisp files, and you make changes to some of them, you can use the byte-recompile-directorycommand to recompile only those Lisp files that have been changed since being byte-compiled (analogously to the Unix makeutility). Just type M-x byte-recompile-directory Enterand supply the name of the Lisp directory or just press Enterfor the default, which is the current directory.

If you write either large programs or long documents, you have probably been caught at least once in a situation where you've made changes that turned out to be a bad thing, only to be confused and stymied because you weren't sure exactly how to reverse them and get back to a known good state. Or, perhaps you've released a program or document to someone else, then gotten a bug fix or a comment that you couldn't integrate properly because you couldn't recover the old version that person was working with. Perhaps you're a member of a development or documentation team and have felt the need for some way to keep change histories, indicating who was responsible for each change.

These common kinds of problems can be addressed with a version control system . A version control system gives you automated help at keeping a change history for a file or group of files. It allows you to recover any stage in that history, and it makes getting reports on the differences between versions easy.

Today a variety of version control systems are widely available on machines that run Emacs. Some are commercial, but there are a wealth of free, open, and powerful choices, and it seems appropriate for our discussion to focus on these. Historically, Emacs evolved largely in a Unix environment alongside the SCCS and RCS systems, and its built-in support for version control reflects their approach and terminology. Today the most popular by far is CVS (which builds on RCS, giving it more flexibility and power), and there is a new system called Subversion that is starting to catch on. Preliminary support for working with Subversion shipped with Emacs 21.3.5; its documentation suggests you check the Subversion site, http://subversion.tigris.org/, for updates.

Given that when you need version control, you generally need it very badly (and you have enough other challenges to occupy your mind), it's not surprising that most integrated development environments today offer automated support for these tools. And if any other IDE does it, by now you can certainly predict that Emacs does too!

In this chapter, we'll introduce you to the Emacs facility called VC, an Emacs Lisp minor mode that makes using version control systems very easy. VC runs all version control commands for you (using Emacs' subprocess facilities in the same way that compiler modes do). VC hides almost all the details of their interfaces from you; instead, you can trigger most basic version control operations with a single command, with Emacs correctly deducing what needs to be done next.

As noted above, the VC architecture was designed with the behavior of RCS in mind. So as we explain VC, we'll explain the RCS terminology and behavior as Emacs presents it. Where needed, we'll point out key differences in the way CVS behaves. Subversion, in turn, is being designed as a more modern version of CVS, and acts like CVS with respect to its interactions with Emacs.

Each file under version control has a change history that consists of an initial version and a series (or sometimes a branching tree) of subsequent revisions .

To make a file version-controlled, you must register it; that is, you must tell the version control system to treat the file contents you're starting with as an initial version and begin maintaining a change history for it. [85]

To change a registered file, in the old days you'd have to check out the file. Doing so notifies the version control system that you're modifying it. Under SCCS and RCS, this would lock the file so that no one else could check it out until you were done (anyone else could still look at it, though). This limitation was one of the major motivations for the development of CVS, the Concurrent Versions System, which doesn't make locks. Instead, it tries to reconcile any concurrent changes at the time that they are committed, as described below. Even so, some developers prefer to configure CVS to keep files locked at the OS level until they consciously decide they want to make changes to one of them; this largely mimics the RCS experience, albeit on a voluntary basis.

In a system like SCCS or RCS that uses locking, you may sometimes find that you can't check out a file because someone else has it locked already. Perhaps that person checked it out and wandered away, so that the lock is stale. You may want to steal the lock— that is, seize control of the work file with whatever changes the other person has made and take responsibility for checking in a clean set of changes yourself. (It's bad practice to do this casually!) Again, this hasn't generally been an issue since CVS made concurrent edits a practical option—recall that the "C" in CVS stands for "concurrent."