Emacs tips

My experiences with Emacs:

I have used the following editors on Unix: vi, emacs, edt, tpu. I settled on emacs because it was much more versatile than vi, and because edt and tpu did not meet my expectations and are considered "legacy" products.

I write this at the suggestion of Adam Para. It is meant to be tantalizing, but not comprehensive. It's an ecletic description of hints, tricks, things I learned later than I wish I had, etc.

Before getting too far along, I better say that the on-line documentation is very good. The keystroke "C-h" initiates it. I should also say that I do not use Emacs with X-Windows; I am using it from Versaterm Pro on a MacIntosh (now upgraded to a Gateway PC running Windows NT and HostExplorer for Windows NT 6.1.0.0 from Hummingbird Communications Ltd.). I therefore invoke it as "emacs -nw". From home, my use is very similar--from there I use "Procomm for Windows" on a 486 (now upgraded to a Compaq Presario 5794), and dial up the lab's access number.

Emacs on X Windows has features using the menu and the mouse, and the mouse buttons. One can use the menu bar from non-X Windows terminals, but it's awkward and I don't do it.

There are numerous variants of Emacs. At the time I first wrote this I was using GNU Emacs, version 19.34. Another variant is XEmacs. more The Fermilab Computing Division is dropping support for GNU Emacs and is only going to support XEmacs, so I have since switched to XEmacs 20.4. That switch is discussed at the URL just given.

"C-h t" gets you started on the Emacs tutorial, which I found quite useful when I first started with Emacs.

"C-h i h" gets you started on the Emacs Info tutorial, which is a good way to learn how to use the tree-structured documentation.

"C-h m" gives help that is context dependent. It utilizes the documentation included with each function definition for whatever mode you happen to be in in a particular buffer.

I better put here the name convention for control character and "Meta" character. "C" is the control key, so that, for example, "C-c" is control c (sometimes indicated as ^c). The "Meta" character on my keyboard is the escape key. It is indicated as "M", so that, for example, "M-x" is the escape key followed by "x". On X Windows I am told that there is a real Meta character. I indicate "M-C" where the documentation indicates "C-M". This is because, without a real Meta key, the order is escape key first, then control key held down while striking the next letter. [this stuff is also discussed when you first invoke emacs].

Emacs features:

I use the following features in emacs:

I might add at this point that the hanging indent text shown above is produced by utilizing the mode "Indented Text Fill" in GNU Emacs. This is useful for simple documentation. The indentation is produced automatically as one types--styled upon the previous line. [you won't see the hanging indents on a browser, however, since it ignores such things--you'll have to look at the file itself]

Interactive Shell

The interactive shell has many nice features. It is invoked by typing "M-x shell". One can have several interactive shell buffers going at once, by using the "M-x rename-uniquely" command (since Emacs has name completion in its command minibuffer, one doesn't have to type each of these words in full). Assuming one gets a bunch of output from one command executed from the *shell* buffer, one can jump to the beginning of the output by the keystroke "C-c r". After looking at the output, if one wishes to discard all of it, one types "C-c o".

One disadvantage of the *shell* buffer is that it acts like a "dumb" terminal. This is disadvantageous when utilizing help from PAW, Adamo, or dbx--but not fatally so. Utilizing paw, adamo, or dbx when I want to make extensive use of help is an occasion when I will suspend Emacs and directly use tcsh.

The *shell* buffer redefines paragraphs to be a command and all its output. This is something I have only recently begun to use. Movements by paragraph are keystrokes "M-{", "M-}".

The "M-x cd" command is useful if one finds that file name or directory name completion is not working as expected in shell mode. Normally, Emacs tracks the use of the "cd" command in shell mode. However, under circumstances I don't understand, the tracking doesn't work. For a while I thought that "M-x pwd" would somehow correct the problem, but it just shows which directory the interactive shell is using. "M-x cd" shows you what directory the interactive shell is using, and allows you to change it.

tcsh

If one's shell is tcsh when emacs is invoked, there is one bizarre thing that happens when one goes to the interactive shell in Emacs. Every line of output from a command invoked from the interactive shell has ^M appended to it. However, not to worry, Emacs has a solution. It is the line:
(add-hook 'comint-output-filter-functions
                    'comint-strip-ctrl-m)

inserted into your ".emacs" file.

Every week this is an item that gets into the newsgroup "gnu.emacs.help" in some fashion or another. The solutions are quite creative.

Info:

Within an info "document", there is a tree structure that is given by "menus" within the text. One may choose from the menu and make a jump. There can also be individual cross references within text that can be followed. There is a method of back-tracking along the path of jumps that one has taken (the letter "l" does this).

Info trees typically have indices. The letter "i" allows you to start a search for an index entry. The character "," continues the search--once it is started. Of course, you may view the index directly and search it by other means, but I have found the "i" and "," search to be very powerful.

As an example of the use of Info, let me take CVS (Concurrent Versions System). I use this because for a long time I didn't realize that CVS is distributed via a FSF license (Free Software Foundation--the people that distribute emacs, gcc, gdb, gawk, etc.). I was using what I found on WWW for CVS documentation (actually Lynn Miller lists some CVS URLs on her Minos page Source Code Repository).

Even though the HTML CVS documentation is hyperlinked, there were some things there that looked like cross references that weren't hyperlinked. These always puzzled me, until I read somewhere that CVS is distributed from FSF. That was a great big "aha", since then it was a pretty sure bet that CVS Info files existed--perhaps even somewhere on FNALU. Sure enough, I could find them and link them into the Info dir structure. With that, I could see that the puzzling "cross references" were indeed Info cross references that hadn't been implemented as such in HTML. The CVS Info documentation was equal to or better than anything I had bookmarks for on the WWW, and it was a lot more convenient for me--since I do a fair amount at home where browsing the WWW is done via CompuServe and costs $ (plus CIM hogs the modem and doesn't want to share it with ProComm for Windows).

Inside Emacs, the top level of Info can point to all manner of documentation. That for Emacs is one menu item on the menu that is displayed. One can link in any Info files one finds useful. To see how to do this, examine "~wehmann/emacs/info/dir". I point to this with the environmental variable INFOPATH. See "~wehmann/.login" to see how this is structured.

One can jump directly to an Info node via the letter "g". The node can be qualified by its file name. For example, "(cvs.info)Invoking CVS" is a nice reference menu of all important CVS commands. The "cvs.info" file in my case is found using an environmental variable, from the top level Info directory. I have to open it first from the top level; using the letter "g" to try to open it won't work--since it isn't in a standard place that Emacs looks.

Dired:

I use Dired buffers constantly. They can be created by the keystrokes "C-x d" and then specifying a directory. One is then in "Dired" mode, and there are a whole set of neat operators defined. One can "mark" several files and perform an operation on all of them at once. As an example, one can mark a set of files with "m", and then use "R" to rename them all to another directory.

As an example of something sophisticated, I write PAW ntuple files (output from GNUMI) to "/afs/fnal.gov/files/data/minos/d1/10_mu/temp", and I call them "aux.paw", "aux2.paw", "aux3.paw", etc. I run paw from "~wehmann/muon_studies/paw", so I symbolically link the ntuple files to that area. However, since I also have a "9_mu" area on the auxiliary disk, I want to link "aux2.paw" as "10_mu_aux2.paw". I do this by marking the ntuple files in the Dired buffer, then I use the "% S" Dired operator with a prefix of 0 (see the Emacs Info document for an explanation of the use of prefixes to a command). This allows me to use regular expressions to name the symbolic links as I have indicated.

Etags:

See "~wehmann/emacs/tags" for examples of shell scripts that create etags files, and etags files themselves. This is very useful for exploring code that you haven't personally written. It is even useful for jumping to locations in code that you have written yourself.

"M-x tags-search" will ask you to specify a regular expression for a search in all the files mentioned in your etags file. For example, if you have a collection of Fortran files with which you are working, you can build an etags file for them. Then you can use that etags file to specify the set of files in which to do the "tags-search". "M-," continues the search after each instance of finding the desired expression.

Customizing Emacs:

Emacs can be customized by entries in the "$HOME/.emacs" file. Emacs is written in C and Emacs Lisp. What appears in the ".emacs" file is Emacs Lisp expressions. While that may seem "off-putting", the syntax of Emacs Lisp expressions can be picked up readily from the documentation--at the level necessary to add things to the ".emacs" file. Emacs always starts up a buffer which has "Lisp interaction" as its mode. In this buffer, one can try out Lisp expressions before institutionalizing them in the ".emacs" file. "M-C-e" goes to the end of the Lisp expression, and "C-j" evaluates it. The result of the evaluation is displayed in the buffer.

I have found it useful to preserve some Lisp expressions to be used interactively, in the file "~wehmann/emacs/scratch_setup.lim". I have set up the ".lim" suffix to be recognized as corresponding to "Lisp Interaction", so that when I open that file, the buffer I get has the proper mode. Most of what is in that file are Lisp expressions to switch which tags file, or sets of tags files, that I wish to use. One "gotcha" that I have experienced is that there is not always a smooth switch from one set of tags files to another. This was one motivation for having the "scratch_setup.lim" file. Even now I cannot predict when I'll experience trouble switching which tags file(s) I am using.

Keyboard Macros:

Emacs has a facility for creating keyboard macros. These can be temporary or can be saved in the ".emacs" file. They are combinations of keystrokes (which can be explicit emacs commands). I have several saved in my ".emacs" file. One jumps to column 72 on a line. Another copies one line of text from one buffer to another (with my screen vertically split into two windows). Another copies multiple lines of text from one buffer to another. Still another puts a buffer into Indented Text Fill mode. Another still shifts what is displayed by 30 characters, so that I can see more of lines that exceed 80 columns (my typical window width setting). A final one sets lines so that they appear truncated at the right edge of the window, instead of having them wrap around to the next line.

I should remark here that the keystrokes "C-x C-b" (or "M-x buffer-menu") produce a list of buffers in a special buffer (which of course has certain letters having operator meanings peculiar to it). This buffer is by its nature "truncated", so that lines do not wrap. The keyboard macro that shifts characters left by 30 is particularly useful with this buffer, so that I can see what file corresponds to what buffer. I did learn to set the buffer-local variable "truncate-lines" to "nil" for this buffer, so that the lines would wrap, but I often prefer to shift what is displayed in the window.

Documentation:

I have already mentioned the online Info documentation for Emacs. This is also printed in book form by the Free Software Foundation, and can be purchased from Books and Bytes in Naperville. The Info files and TeX files can be generated from the same, master texinfo file. A portion of the purchase price supports their software writing efforts (which Fermilab cannot do directly!). The book comes in handy when one is away from a computer terminal; for example, on an airplane trip one could read about Emacs features one hasn't yet discovered via online reading. This book has a GNU Emacs Reference Card bound into it; this is a one page, double-sided summary of Emacs keystrokes and commands. It also comes as a TeX file (or postscript) that can produce one page, double-sided output on a laser printer with the duplex printing feature. The file is saved locally as "~wehmann/misc/to_save/refc_v19_3col.ps".

The O'Reilly book on Emacs is fairly decent, but it is getting dated. It does have a section on writing Lisp, which may come in handy. There is a more recent one on writing extensions to emacs (i.e. learning to understand and use elisp).

RMAIL

RMAIL is but one choice for reading mail within Emacs. It comes with the Emacs distribution. RMAIL does not send mail; sendmail does that (from within Emacs); one can reach sendmail from within RMAIL by typing the letter "m". In general, sendmail is entered via C-x m.

Here is a URL pointer to the RMAIL part of the GNU Emacs manual.

One comment here is that the RMAIL mode also invokes a concept known as "narrowing". In this case you'll only see one mail message in the buffer, even although the file that is loaded in the buffer has as many mail messages as you've allowed to accumulate there. The specialized one letter operators will only have a span of this one mail message. For example "." will go to the top of the mail message, "SPC" will scroll down one screenful, "DELETE" will scroll up one screenful, "e" will change mode enough that you can edit the mail message (useful for getting rid of some of the header crap if you intend to save the message for a while), "o" will output the mail message to another file in RMAIL format. "Narrowing" is a general concept that is "turned off" ordinarily, so as not to confuse the Emacs novice. It can be used in other contexts besides RMAIL files.

"Narrowing" for an RMAIL file can be turned off. For example, if one wants to move a bunch of mail messages from one RMAIL file to another, this is the way to do it (with care, of course). This operation is a bit tricky, however; each time I attempt it, it takes me several tries to get it right.

There is a special header in a RMAIL file that tells Emacs to treat the file as such when it is "visited" by a buffer. This also is a more general concept. Special headers can be included in files to give Emacs instructions. One such tells Emacs to visit the file in text mode--instead of "fundamental" mode, which is the default for a file without a suffix that Emacs recognizes as forcing a particular mode.

The structure of the RMAIL files is explained in the "etc/BABYL" file that comes with the Emacs distribution.

Mime enclosures can be handled in RMAIL by a choice of different extension packages. A good reference for this topic is Emacs and Mime. I've chosen "rmime" (RMIME --- Decode MIME messages inside Emacs (works with RMAIL, VM and mh-e)). It took me a while to realize that for each enclosure rmime inserts a line at the end of the mail message's buffer window which can be activated by typing C-c C-c. The cursor must be moved to that line before typing C-c C-c. The line either says explicitly to use C-c C-c, or it is simply the description of the enclosure (e.g. "near.ps"). The action initiated by C-c C-c is either the creation of a file that can be shipped by FTP (binary transfer) to another computer, or else a file is created in \tmp and passed to "metamail". Metamail looks in your .mailcap file to see if there is an application specified to do something with the temporary file. For example, for a postscript enclosure the temporary file would be handed off to a Ghostview background process--if that were specified in the .mailcap file.

I found that I had to add to rmime.el the two lines:

(defalias 'rmime-application/rtf 'rmime-application/octet-stream)
(defalias 'rmime-application/msword 'rmime-application/octet-stream)
in order to handle MS Word 5.1 enclosures made by Netscape 2.01 and Eudora Lite on my MacIntosh.

"M-x rmime-mode" toggles the RMIME mode of the buffer containing the mail message and the enclosures (RMIME is a minor mode for the RMAIL major mode) . There is a corresponding indicator at the bottom of the screen. If the mode is "off", you see everything. Editing the message in the RMAIL buffer (i.e. typing "e") turns RMIME mode off (note that one exits from the RMAIL edit by typing C-c C-c).

RMAIL messages can have "labels" attached to them, to indicate their subject matter or status. Some labels are standard--such as "edited", "answered", "resent". It is also possible to make a summary buffer of all messages in a RMAIL file--by typing "h".

Modes

There are a number of different modes in Emacs--both major and minor. An example of a major mode is Fortran mode. In Fortran mode, Fortran source code may be semi-automatically indented to show nesting of "if" - "endif" combinations, "do" - "end do" combinations, etc. The keystroke combination "C-c w" puts a marker on the screen at column 72, which is useful if the compiler is going to ignore columns 73-80 and beyond. A "region" of source lines may be defined, and all turned into comments with an Emacs command--or vice versa. From Info node "(emacs)Fortran Comments":

`C-c ;'
     Turn all lines of the region into comments, or (with argument)
     turn them back into real code (`fortran-comment-region').

Emacs invokes Fortran mode for files with suffixes ".f"; it can be told to do so for files with suffixes ".F" (useful for Unix flavors where f77 doesn't automatically invoke CPP ahead of the compiler).

Another nice feature of Fortan mode is that one can break a line nicely, with the next line already set up as a continuation line ("M-C j"). Each major mode tends to redefine the meaning of certain keystrokes--especially the ones starting with "C-c". The current definition can be seen by typing the keystrokes "C-h m" (the use of "C-h m" is something I stumbled onto not too long ago--even although it can be found in the documentation).

For those persons writing Perl scripts or shell scripts, Emacs has modes that correspond. I haven't discovered the particular benefits of these modes yet. Of course, there is a C mode and a C++ mode. I mentioned earlier a HTML mode, as well as TeX mode.

View mode:

A file can be "viewed" in a buffer, instead of "visited". When it is "viewed", it is read-only, and there are some additional keys defined for moving around. One reason I mention this is that I found that the "M-C s" regular expression search doesn't seem to work in standard fashion when "viewing" a file.

Matching (){}

Along with indentation features that understand language syntax Emacs has commands that can find matching parentheses or brackets. This is explained in Info node "(Emacs)Programs". The commands are C-M-f and C-M-b. This feature can be quite useful when conditional constructs get quite convoluted. A syntax table is used for this purpose; it varies with choice of major mode.

If one gets to the point of trying to understand elisp programs written by others, there are a pair of useful commands that understand the structure of an elisp function. They are C-M-a and C-M-e. These can be very useful for finding the beginning and end of an elisp defun expression.

Rectangle editing

Emacs has rectangle edits, with cuts and pastes. Cut text can be stored in registers, and recalled from registers. The same registers can be used to mark locations in a buffer (in addition to this there is a permanent bookmark feature which is described under a separate heading).


Comments to: Alan Wehmann(wehmann@fnal.gov)
Last modified: Wednesday, February 24, 2000