Why Emacs?

Why I became an Emacs user

Or, My long arduous journey to the One True Editor

v1.1 © 2000 Charles Sebold

I have to be honest; I was driven to Emacs purely by ideology. But I stay with it because there is nothing else like it. You may see what I mean if you follow my journey briefly.

[Note from eleven years later: so much of this is outdated, and in a lot of ways this is the history of my initiation into a Unix worldview, not just an Emacs one.  But as a friend has pointed out, Emacs isn’t really a Unix kind of tool, it’s a Lisp-machine kind of tool.  Anyway, all statements of fact in here are disclaimed, and just remember, I was comparing XEmacs 21 and GNU Emacs 20 here, when I was doing any comparisons at all.]


Like most people who didn’t start out with Unix variants, my first editor under Unix was pico. It used control-keys for various functions, defaulted to wrapping your words automatically, and is really a decent complement to the Pine email client, if one’s previous idea of email was either America Online or Eudora 1.x for Macintosh. All the most common commands were right on the bottom of the screen, and one could easily navigate as far as that went. You wouldn’t want to write a book in it, or a perl script, but overall it worked.

At this point my exposure to Unix was a dialup shell account into a Solaris box. As long as I could run Pine and Lynx I had little use for anything else.

I experimented briefly with GNU/Linux on a 386, but didn’t have all the hardware support I needed (this was back in the 0.99 kernel days), so I had to drop it, and ended up selling that box. Little or no need for an editor this time, but when I needed one, I made sure pico was installed, and continued to use that. What “Linux community” there was at this time was largely academic, and I only knew one or two people who had used it. I tried vi a few times, but I had to have reference cards near every time, and I felt out of my depth. I felt no pressure to change, and I didn’t see why anyone would need more out of a text editor. I figured, if you needed more, it was time for a word processor, which was a different story altogether. And who would use a Unix word processor?

I went to work for a Macintosh resale company about this time, and we had a ton of old Macintoshes lying about (at that time, 68040-based Macs could still sell well, so I had a few IIci’s at my disposal: 68030-based machines, running around 25MHz, with 8MB RAM and whatever hard drives I could scrounge up). I didn’t think much about it until I found out that, while Linux wasn’t booting up on any of these machines yet (it is now, but I haven’t tried that yet), somebody had a Unix that had come a long way: something called NetBSD. I felt some pressure to understand the Unix phenomena, since my closest friend at the time was going to college, majoring in Computer Science, and doing much of his work on Sun’s. I read up on it on the ‘net, joined the mailing list for Mac users (port-mac68k, still going strong, and I’m still a member), and began to try to install it on a IIci. Eventually I got it going. That was the first time I’d see every trace of graphics disappear from a Macintosh screen (except for some Macsbug moments), and it was spooky. When X-Windows worked at all, it was in black-and-white, and took so much time to get started that it didn’t seem worth it.

However, now I found myself the erstwhile system administrator of a Unix machine, and I needed to edit a lot of files (NetBSD, like the BSD ports in general, didn’t have a lot of cute little graphical tools to help in installation, a fact which I have thanked God for many times over the recent course of my career as a Unix sysadmin). Pico just wasn’t going to cut it, but these things came with vi, of course. Time to learn it.


Learn it I did. I never became a power-user, but I became very comfortable with the basic editing keys. I only ever reached outside the basic QWERTY layout to hit the ESC key; I was completely weaned from arrow keys early on. I quickly got to a point where I was faster editing in vi than on a Macintosh running SimpleText. Over the course of a year and a half, I installed NetBSD several times on several machines, including (eventually) a Quadra 650 and an 800. Vi ran very fast on those machines; in fact, I could even run X usably on them. At this point I barely ever heard of any other editor; once in a while some “old-timer,” as I must confess I thought of them, would ask about how to compile Emacs for NetBSD, and they were pointed to a FAQ or Meta-FAQ or two, and you’d never hear from them again. I didn’t know the difference, but I did know that it was a huge download, whereas vi came with every Unix with which I was familiar. I didn’t even know there was a holy war between vi and Emacs users, much less a split among Emacs users. Heck, at this point I didn’t know there were multiple clones of vi.

Soon Apple announced that they were funding a port of Linux to the Mach microkernel, to run on their Power Macintosh 6/7/8100 line. I grabbed this as soon as Developer Release 1 was out, and it had vi. I could handle this. It seemed to work pretty well, and a usable X-Windows with color (which at this point NetBSD rarely had on Macintoshes) was nice. But I still never heard about Emacs.

Right about this time I switched jobs, and became a Mac and Windows tech support person for a large organization (for which I still work). I installed MkLinux on a Power Mac on my desk, and used it a bit, but overall I was stuck in a world of proprietary operating systems that didn’t work well. I got a 7200 and tried MkLinux on it, then switched to LinuxPPC (all you had to do back then was get a LinuxPPC kernel and write some boot blocks, then use Open Firmware to boot it), and now we had a Netscape (which meant a decent email client, which is a major need for me on a computer). (By the way, I no longer consider this a decent email client.) I ran it for a while, got DOOM working, fooled around, and formatted it and reinstalled Mac OS. Then we put one up as a server, running LinuxPPC and MkLinux’s userland binaries. It had a bad Ethernet card, and we had to scrap it, but I did all my remote admin using vi. It was fast and I was familiar with it.

Eventually I somehow landed the job of Unix sysadmin at my place of business, drawing mostly on my old knowledge of NetBSD on those old Macintoshes. As a result, I got a laptop and a copy of RedHat Linux 5.2, and installed it. This was my first full-time Linux computer. This was also my first taste of a slightly different editor: vim. Yes, Vi IMproved. After upgrading it to v5, it did something I didn’t expect: it colored the text according to syntax rules.



I upgraded every machine I had to VIM 5. I saw how it could tell what kind of code it was based on the filename, and made sure that all my filenames corresponded properly. I tweaked it a bit when I could. I made sure that it always displayed the same everywhere. This is about the time I started to realize that there were Emacs users out there, and they were serious about their own editor, too.

I started to need more from the editor. I started needing to do complex search-and-replaces. I wished that the syntax modes covered more syntaxes, or handled the current ones better. The syntax files themselves weren’t too hard to tweak, but it was still a pain; one had the feeling that they had been grafted onto the existing application haphazardly. I also began to wish for some uniform way that syntax would dictate the use of tabs and indenting. And I started thinking about things I would like to do regularly to text files, and how I would have to implement them as awk or perl scripts outside of the editor to make them work. What a pain. When I tried to learn how to do the things I could do in vim, I had to read the online help, which was nearly impossible (or at least incredibly counter-intuitive) to navigate.

Silly things that should never have tripped me up, started to get in the way. It began to annoy me that I had to use one set of cursor keys in insert mode, and another set in command mode. Sure, this can be tweaked too, in vim. And I started to do so. But it seemed funny that I had this feature automatically in pico.

This is where ideology starts to creep in. Sure, I appreciate the gratis nature of the GNU tools, but I began to see how important it was that they be libre as well. (English uses the same word, “free,” to describe both zero-cost and zero-restriction states. As the Free Software Foundation likes to put it, it’s the difference between “free beer” and “free speech.”) Now, vim is technically free software in the “free speech” sense, I believe, or so close that it’s pretty much there. And since it is, for all practical purposes, “the” vi that ships with GNU/Linux distributions, I could feel fairly good about my growing resolve to use free software whenever possible, and hopefully eventually use it for everything.

But then I started to learn more about the names behind this revolution, and one figure seems to loom across the landscape: the founder of the GNU project (to create an improved Unix-clone out of entirely free software), Richard M. Stallman. A lot of people can’t stand him, but his pioneering work on the GNU C Compiler (gcc) made the entire free software movement possible, even the BSD ports that aren’t based on a kernel licensed under his General Public License. (The Linux kernel is licensed under the GPL.) I followed his history for a bit, and I was impressed by the scope of his vision. I admit to being turned off by a lot of the things he says or the attitudes he projects, but I agree wholeheartedly with his basic principles. All software does not have to be free, but most software used by people should be free. The ultimate good would be a computer society where all software was free, and anyone could use it or contribute code to make it better. While this philosophy is not entirely useful from an economic standpoint, considering most modes of exchange, in the virtual world of software it makes the most sense, and helps to make more “have-nots” able to become “have’s.” There are plenty of better ways to express this, so I’m not going to do it here.

EMACS: Embarrassed Manual-Writer Accused of Communist Subversion

In looking over RMS’s history, I remembered that the other piece of software he is famous for, in addition to the GCC suite, is the editor called Emacs. And now that I was aware that a very large and vocal contingent of Unix users were Emacs users, I began to wonder if it was a good editor or not. I found it interesting that the one piece of free software that came with my employer’s implementation of Digital Unix was Emacs 19.34. My curiosity was also piqued by the idea of any piece of software (besides possibly AutoCAD) going through nearly 20 major revisions. What was this thing? (Note: since I have found out that, by the original numbering scheme, the current version would be something like 1.20.6, not in fact 20.6, but RMS felt it was silly to continue tacking the “1” on. However, the revisions from 19 to 20 were pretty significant, so I think that possibly my original picture of this was justified.)

I started to read up on it a bit. The information I found was fascinating, and I learned quite as much from Emacs’ detractors as I did from its enthusiasts. Emacs stood originally for “Editor MACroS,” and was written as a series of extensions to the TECO editor, running on a PDP-10 at MIT. Other names have been suggested (from /etc/JOKES in the Emacs distro):

  • Eight Megabytes And Constantly Swapping
  • Even a Master of Arts Comes Simpler
  • Emacs Manuals Are Cryptic and Surreal
  • Eventually Munches All Computer Storage
  • Even My Aunt Crashes the System
  • Esoteric Malleability Always Considered Silly
  • Generally Not Used Except by Middle Aged Computer Scientists
  • Extended Macros Are Considered Superfluous
    and of course the one that comes closest:
  • Escape-Meta-Alt-Control-Shift (the modifiers used and overused
    throughout the editor)

In the immortal words of Lord Percy Percy, though, “I like a challenge!”

EMACS: Excellent Manuals Are Clearly Suppressed

My wife wanted a project to take on, so I suggest she try learning Emacs. This would be a useful experiment, and my time was important to me, so I didn’t want to waste it chasing an editor when I was an old dog who couldn’t learn new tricks. Well, she asked if there was documentation handy, and I looked and sure enough, there was a manual, free like the software. First I downloaded the manual in raw PostScript format. It took a bit to print that; I couldn’t do it in duplex using GhostScript and my NT network at work, I had to convert it to a PDF, then switch to Windows and print it using the Windows Acrobat Reader and Windows print drivers. It took over two hours. Not a good sign.

When I was done, I realized that I could use this stack of paper to increase my upper-body strength. Seriously, it was too big to bind in any way. This was daunting. I had printed it duplex, too, as you’ll recall. Yikes. Well, maybe I could just try it.

EMACS: Elsewhere Maybe All Commands are Simple

Tracey wasn’t moving too fast to switch (her Linux box broke down with hardware problems twice, so one could see why). I got the RPM’s for RedHat 5.2/Intel, and installed them all on my work laptop. In fact, I even went to the trouble of changing my EDITOR environment variable to point to Emacs. When learning a new computer program, I almost always have to do it total-immersion-style; the “root, hog, or die” philosophy. If I have to figure it out, then there’s a chance that I will.

By this time I had two full-time Linux machines: my laptop at work, and my Power Macintosh 8600 at home, running LinuxPPC. To be totally immersed in Emacs, I would have to get Emacs running on it, too. Thank goodness, LinuxPPC 1999 came with RPM’s for it. But this wouldn’t be the end of that nightmare.

I started using it. Boy, did it ever take a long time to come up, compared to vim. And on the Intel laptop, it defaulted to around 6-7 MB. Well, I had 64, so it wasn’t that big of a deal. I started to learn how it worked. And I was very surprised by what I found.

EMACS: Epileptic MLisp Aggravates Compiler Seizures

Emacs is just barely an editor, at its most basic level. Mostly it’s a Lisp interpreter with pages of memory called “buffers,” and everything you do in Emacs is an execution of a Lisp command. I mean it: everything (or practically everything). This is why all the Emacs zealots rave about extensibility; whereas you might be able to coax vim into talking to outside programs you write to make changes in your files, here in Emacs everything you do is running programs to make changes in your files. No wonder it’s so big! Look: when I ask it what the “k” key does, this is what it tells me:

k runs the command self-insert-command
   which is an interactive built-in function.

Insert the character you type.
Whichever character you type to run this command is inserted.

So, hitting “k” (or any standard character on your keyboard) runs a little function that inserts the character you typed into the text buffer. All editors really do this, but this one exposes the process to you. Whatever for?

The answer lies within the very heart of the “free software” philosophy: it is exposed so you can change it if you want to. Why would I want to do that, you may ask? What would I ever want to do with the “k” key, besides insert “k” into a text buffer? Ah, now consider this. Let’s say…you want to do something perverse, like write a vi emulator in Emacs Lisp? (Don’t get any ideas, there are a couple out there already, and VIPER is superb.) You can rebind the “k” key, if you are in an emulated “vi command mode,” to do what the up arrow does! You just need to change the keys around so that it runs the command “previous-line” (that’s what Emacs reports when I hit the up arrow). Do this with enough of the keys, and I have a vi command mode which acts as much like the original behavior of vi as I want.

Emacs Lisp isn’t just good for key-binding though. Its predecessor, the Lisp out of which it grew, was a fairly powerful language, although it appears a bit odd to those of us who grew up on Basic and learned C and Perl as we got into real computers. Emacs Lisp is certainly excellent for the text manipulation that it does. Consider the next thing we have to have, to rival vim: syntax coloring. Instead of writing a somewhat arcane and limited syntax file for vim, we can write a much more arcane, but much more intelligent, Lisp program that will use the right colors and font modes to describe the terms in our shell scripts, C programs, HTML documents, etc. We can also get it to analyze the actual contents of the file, and determine if it needs to color my shell script assuming Korn shell syntax, bash, c-shell, or whatever.

But why stop there? Why not tell it how to indent these blasted documents, so that they’re readable by somebody other than the author? I mean, you’ve got a full-featured language interpreter here, and it can deal with regular expressions (similar to Perl’s usage of them), so why not take advantage of it? You will find that, in c-mode for example, hitting <TAB> will not insert a tab character, but will instead analyze the context of the line you’re on and indent it properly for you. Take a second to see how much power that gives you.

You can surely see where this is headed by now.

EMACS: Each Mail A Continued Surprise

I was happily running Mutt, a very fast and suprisingly customizable little text-mode mail client. It hooked seamlessly into my PGP setup, it was IMAP-capable, it was fantastic. However, since this represented sometimes as much as half of my text-editing in a day, I would have to teach it to use Emacs as well. I set it to call Emacs rather than vim to edit outgoing mail…

And watched as it started up a new copy of Emacs every time I wanted to send mail, reply to mail, or whatever. Ugh. I changed it to run Emacs in its own xterm rather than opening up an X-capable version, but it still took forever, and ate more of my RAM. Suddenly I started to sour on the whole project. I mean, I liked the idea, but I couldn’t afford this kind of RAM usage in the normal course of a day, over and over. How did they use this back when CPU’s were slow and RAM was expensive? Then I found out about Emacs’ “server-client” mode. You tell your first copy of Emacs that it’s a server, and instead of calling it from external programs with emacs textfile, you called it like this: emacsclient textfile. Now instead of starting up a new copy of Emacs, it uses the existing copy to edit your new file (or email, or whatever). No added RAM usage aside from the document (and a nominal amount for the server, hardly anything really). You just have to have a copy of Emacs, in server mode, running at all times you might call it from the mail client, and one rapidly discovers how convenient it is to have an editor there whenever you need it.

Now you get to see how much of a whiner I really am. I started to get fed up with having to switch windows all the time to go from the mail management in Mutt to the mail editing in Emacs. Again, I was about to switch back, when I remembered that there were people out there who were actually reading their email in Emacs. I mean, if ELisp (that’s Emacs Lisp) is so good at this text manipulation, why not turn the handling of the email itself over to the editor? And apparently it was able to access all the usual network ports, devices, etc., just like our Perl and Python interpreters do. So why not?

What follows is the biggest, stupidest thing about this editor, the way it comes configured as default. If you go through the menus, you will see one called “Tools: Read Mail”. Don’t be fooled. You don’t want to do that. Trust me. Let’s see what that menu option does:

menu-bar tools rmail runs the command rmail
   which is an interactive autoloaded Lisp function in `rmail'.

Read and edit incoming mail.
Moves messages into file named by `rmail-file-name' (a babyl format file)
 and edits that file in RMAIL Mode.

Let me emphasize this properly for you: It moves your messages into a babyl format file.

A what, you say? A babyl format file. That would be a file that is formatted differently than any mail format you have ever seen. Most mail clients will never touch your mail again if it finds it in babyl format. You will lose everything you had in that inbox, unless you keep a cool head. I flailed around for a moment, until I found a utility that would reverse the process. Then I paused for a moment of bleakness. I had begun to dream of a day when I could do most of my work in a single window, switching to different tasks with the rapidity of a few keystrokes. No more screwing around, mousing around my (then) Enlightenment-driven virtual desktops, trying to find that mail client that was hidden behind an IRC window, or Netscape. I would have it right there, all the time, along with everything else, everything but telnet sessions and a web browser, and maybe an MP3 player [which I later found out, could also be controlled under Emacs!]). I was going to be so efficient! But I couldn’t even read my mail. Honestly, this was frustrating. But I didn’t dare switch irrevocably to Emacs rmail; I had too many eggs in my other baskets.

A Google search for “emacs mail client” later, and I found VM. VM 6.75 could get mail from IMAP mailboxes as well as POP mailboxes as well as local Unix mbox mailboxes, and could read just about every format out there. A little bit of fiddling around and I was able to make it cooperate with procmail (my filter system), and everything was fine. It has features that Mutt doesn’t have, even. The tradeoff is, VM is running in Elisp, and it’s a little slower, comparatively. Also, to work with a mailbox, it has to read it into an Emacs buffer. This is tricky if you have a mailbox that’s over 30 MB (as I do). Oh, well, I still keep Mutt around for the big bad archive searches I have to do sometimes. An Emacs package called Mailcrypt interfaces with PGP, GnuPG, or whatever you’ve got to provide encryption pretty much anywhere. (By the way, Emacs comes with a newsreader called “Gnus” which is apparently a very well-liked mail client as well; I wish I would have taken the time to try it. Maybe I’ll get around to it someday; if I do I’ll post my experiences.)

EMACS: Easily Mangles, Aborts, Crashes, and Segfaults

Now that I had a good email client I was happy with (just similar enough to Mutt to ease the transition; the tricky bit was learning the new key bindings), it was time to switch to it globally. Time to install VM on the Power Mac and get serious about Emacs. I was converted, no question. I got home, downloaded the tarball (another nice thing about Emacs; all the huge downloads are pretty much over as soon as you get Emacs itself. VM was less than a megabyte; Mailcrypt was under 400K if I remember correctly), unpacked it, ran make…

…and was promptly met with “Segmentation fault”. What? I looked at the Makefile, and it was calling Emacs in batch mode to ask it to byte-compile the Lisp code. In other words, it was calling Emacs non-interactively, in a sort of command-line mode, to compile the Lisp code that VM comes with, into a byte-code that Emacs can deal with a bit faster. Most of Emacs is byte-compiled Lisp, rather than just source. Emacs can deal with either, but one might as well byte-compile it if one can.

I didn’t know any of this; all I saw was, when calling Emacs non-interactively on my Power Mac, it crashed. I tried various experiments, which made it clear that running Emacs in batch mode would always crash it. This was not true on my Intel laptop. I reinstalled the RPM’s. I tried it on a different computer (my wife’s G3, and then my G3 at work). No luck. Emacs had come broken.

Well, no big deal, right? I can always compile it myself! I downloaded the 15MB tarball (two minor releases later than what came with LinuxPPC), unpacked it, and typed ./configure, at which time I found out that it doesn’t deal with GNU/Linux as a generic operating system; it has optimizations built in for certain processors as well. And, without a header file for PowerPC processors, it would not even configure, much less compile. I grabbed the source RPM from the LinuxPPC CD, which contained some additions to make it compile. I tried those. They didn’t work; it failed when attempting to build the emacs executable. How in the world did they manage to make this work if the source RPM doesn’t work? I began to wonder if my system was failing in some way. But everything else worked…

I switched back to the tarball I downloaded from gnu.org, and tried to make my own powerpc.h header file. No luck. I tried to merge the 20.3 LinuxPPC Emacs sources and the 20.5a GNU sources. No luck. I asked on the LinuxPPC list, and was told that I could try byte-compiling the VM sources manually, from within Emacs. I did so. It worked! I finished the installation, and I had a working VM at home! However, the fact that batch-mode didn’t work irked me to no end. It was suggested that I go see if MkLinux had a later one that would work; I got it, and it came with several patches, but still didn’t quite compile. However, I took their patches, merged them with the 20.5a tarball from GNU, and got a working compile. Everything worked flawlessly, and I now had an Emacs I could trust. Instructions and patches for this, by the way, can be found on my main Emacs page. (Note: Emacs 20.7 includes LinuxPPC header files.)

EMACS: Emacs Makers Are Crazy Sickos

Of course, like any text-mode email client in the Unix world, VM choked on HTML. It could send it to Netscape, of course, but where’s the fun in that? It would automatically work with W3, though.

W3? What’s that? That, I was told, is a web browser, written entirely in ELisp, that supports stylesheets, frames, cookies, tables, and even images (more on that in a minute).

I downloaded it. I tried it. It works. It works well. Rendering the page is very slow compared to Netscape or similar products, since the rendering is being done by a program running in an interpreter. But it does work. Amazing. Who would do that? Well, if you use Lynx (Lynx which has no frames, among other things), you can begin to see where the “market” is.

But what about those images, you ask? Well, this was my introduction to the next holy war: XEmacs vs. GNU Emacs. Here’s the very short version of what happened: a company named Lucid was developing a number of integrated tools for software development, and they were connected very closely with Emacs; however, there were features they needed in Emacs at the time (this was before GNU Emacs 19 came out), so they contributed code when they could, and eventually hired the Free Software Foundation’s programmer, so he could work full-time on Emacs. He ended up losing the project (from the FSF’s standpoint) and someone else was appointed to maintain Emacs. There followed a series of problems, as Lucid began to add a lot of features to Emacs, making it a much better product than GNU v18 was, but not following Stallman’s timetable or clearing much of it with him (they felt like having the official maintainer on the payroll was enough, and I must say that from their standpoint one would think that this was the case). They also implemented several things slated for v19 and v20 on their own. RMS didn’t like they way they did certain things (it is hard to tell if he didn’t approve of it or just didn’t understand it fully; there are signs that, in some cases, he looked over the code to try to integrate the projects but couldn’t understand it without some help from the programmer). Jamie Zawinski (now of Netscape/Mozilla fame) was a hotshot programmer at Lucid who implemented quite a few outstanding hacks, but RMS couldn’t follow his work without some significant backtracking, much less merge it into the existing FSF code. He asked Jamie to help him, but the work had forked so far back that nobody would take the time on either side to make it work. Lucid Emacs 19 came out with most or all the features that GNU Emacs 19 promised. GNU Emacs came out a little later (apparently). RMS gave up trying to understand JWZ’s code, and the two projects went their separate ways permanently. Lucid folded soon after, and the project was renamed XEmacs. (The original fork had relied on X-Windows, but that hasn’t been the case for some time.) Eventually XEmacs developed a much easier scrollbar, a completely different way of accessing the buffer internally (while maintaining a surprising amount of ELisp compatibility), and – here’s where the important bit kicks in, for W3 – the ability to display pixmaps in the buffers. In XEmacs, W3 will display images. As far as that goes, it’s nearly a replacement for Netscape, if you can stand the slow render times.

GNU Emacs 21 will supposedly have pixmap support, and may include a better scrollbar (my biggest complaint about GNU Emacs is the scrollbar). XEmacs comes standard with many of the packages that you don’t get bundled with GNU Emacs, including both VM and W3. XEmacs compiles out of the box on LinuxPPC. Importantly for some, XEmacs supports multiple fonts, including proportional fonts, coexisting side-by-side in buffers. It’s pretty snazzy, true, and if you haven’t tried Emacs yet, then maybe XEmacs is for you. It’s quite a broad road, to borrow a Biblical metaphor, and the gate is quite wide these days. *smiles* I plan to discuss my attempt to convert to XEmacs, and my return to the Church of Free Software (Orthodox Stallmanite), in another document, coming soon (check the front page of this section for details).

EMACS: Every Mode Accelerates Creation of Software

Just as vim has certain syntaxes that are loaded or unloaded depending on the filename or the whim of the user, even so Emacs has what are called “modes” to deal with both how text in a buffer should be displayed, and how input should be handled. To touch on an earlier example, if you switch to VIPER mode (if you’re in Emacs now, that’s “M-x viper-mode”, where M- is your meta key, usually either Alt or the one with the Windows logo), the text displayed isn’t changed, but after you determine what level of VIPER mode you wish to work with, you will find that the keys have been remapped to vi-style movement and editing commands.

The modes that have been contributed to work with Emacs are many, and some are truly amazing. I want to demonstrate this with two features that I use together constantly: ange-ftp and DCL mode.

I have to work on VMS systems fairly frequently, and unfortunately I am not in a position to run Emacs on the VMS system itself. (There is a port of 19.34 to VMS, but I have never gotten it to compile successfully.) It’s hard to go to the editor that comes with VMS (TPU/EVE, or EDT) when you’re used to vi, much less when you’ve got something like Emacs. And it’s a pain to ftp the file you need to work on back and forth between your Emacs system and the VMS system…until you find about about ange-ftp. This little gadget allows you to load a file from an ftp host as if it were mounted on your local filesystem somewhere. So, instead of loading a file at “/home/sebold”, I tell it to load the file “sebold@vmshost:DCL/TEST.COM”, which instructs it to ftp the file in the DCL subdirectory of my user directory on vmshost, and load it into a buffer for editing. From there on, I just hit “save” like I normally would, and it writes the file back. This works like a normal directory structure, so you can take advantage of things like filename completion.

Once I load my DCL script and set Emacs to DCL mode in this buffer, I’m ready. When I hit <TAB> it doesn’t insert a tab, or spaces; it checks the current line against the context and indents it appropriately. I can manually change the indentation of the line above, and hitting tab will force the line to conform to the one I changed. This works in most language modes that I am aware of. It’s a lot more fun to write perl scripts when you’ve got someone else taking care of readability chores, believe me.

When I switched to DCL mode, I got a DCL menu (shown here). This menu shows me common DCL-mode-specific commands that I can access either from the menu or the keyboard. The Lisp involved in this mode is very intelligent, and knows where statements begin and end, even when they cross line boundaries. The best thing, though, in some of my procedures which are over 1000 lines, is this feature:

This is the “Buffer index menu” from the top of the DCL menu. It pulls up a list of all my labeled subroutines and sections, and I can move there instantly. I can also look over the list from here and get some idea of the structure of the procedure. This is incredibly useful to me. Not all modes have things like this, but most or all of them have similar features that are more useful in context.

As I come up with more reasons why every system administrator, programmer, and user of a multi-user operating system should use Emacs, I’ll include it here.

%d bloggers like this: