TAHIR HASHMI'S WEBSITE
  COMPS [ Under OPL ]  
Home

Emacs: Working @ the Speed of Thought

MYSELF

COMPS
Linux
Wireless LANs
Sawfish on RH8
Emacs
Why C++

PEOPLE

AUTOS

IMAGES

PLACES

Yahoo! Search

Search This Site
Search WWW

Hold mouse over words above for more information.

Made with Emacs

Get Firefox!

Introduction

Emacs Screenshot

Text editing as an art, science or skill seems to have been forgotten by the masses of people who now claim to be "Computer Literate". The GUI was arguably the most significant facilitator of bringing computing out of the bastions of computer "Labs" where Uber-geeks once used to code away merrily at tiny CRTs displaying sharp green text against the black depths of the screen. The mouse came and worked with Menus and Tool-bars to turn the keyboard into a necessary evil.

I'm not a command-line junkie. I can't possibly live without the GUI. I couldn't have given my site the layout and colors you see without previewing it in a color screen, could I? Yet, I love the keyboard, I like to have the power of command-line available to me because typing on the keyboard is significantly faster than dragging and clicking the mouse around. But the keyboard is injurious to the fingers, you say. It's an occupational hazard! Well, do you remember what happened to your fingers after taking notes in the History class for half an hour? Yeah, they used to ache. Why hasn't the Pen been labeled as a weapon of torture to young kids? Why are the latest PDAs coming equipped with a stylus? Because the pen is the most convenient writing instrument mankind has learned to use. Since I've taken up software as a full-time profession, I've started realizing that when it comes to converting thoughts to writing (electronic or on paper), the keyboard works faster for me.

When you need to have your thoughts expressed as fast as you think, it doesn't matter whether the result looks pretty or the code is correctly formatted. What you need is to convert your set of thoughts, which is a temporary and volatile state of mind, into material before they get corrupted by interfering thoughts of beautification or refinement, which are more-or-less mechanical tasks. If the quickest medium of expression that you have is the keyboard, the simplest but most effective medium of materialization is text. Plain Text.

There are several excellent tools available that break the task of writing documents or software into neat steps. The first of these neat steps is putting things out of your mind and into text. This is essential to aid the process of expressing thoughts first and then acting upon them for further refinement.

For most of the "Computer Literate" people, the right place to go and type is "Microsoft Word". I'm sorry, but a WYSIWYG Word Processor is one of the most unintuitive and obstructive means to express your thoughts, whether it be writing books, writing a letter to Mom or documenting an application. Programmers are no better. They use tools with super-flashy features to break their thought process and make them find ways to use each of those super-flashy features while writing code. These tools are often known as IDEs or RAD tools. When you are out to write text, your best friend is a capable "Text Editor". This is an application that basically enables you to write plain text in a computer and perform some actions on it, like deleting a few characters, to mention the simplest.

Emacs: Text-editing par excellence

Among the myriad text editors available, especially in the Unix/Linux environment, the two most popular editors are Emacs and Vi. Yeah, notepad is one but it doesn't stand a chance before those Big Daddies. Both Vi and Emacs have their followers that are faithful to their favorite editor to the extent that their usage is compared to cult, religion and even "a way of life". The reason is that the underlying philosophies of the two are completely opposite. While Vi is a small good-for-only-text-editing application, Emacs has an entire Lisp engine running under the hood with immense capabilities to assimilate (Borg terminology :-p) extra functionality.

I have used both the text editors and continue to do so, but I find myself using Emacs much much more frequently than Vi. The reason is that Emacs can not only act as a simple text-editor, it also works as a highly capable IDE, document preparation system and a fairly functional shell. People even use Emacs to send email and browse the web but I'm not that great a devotee as them. I do C/C++ programming and debugging, web development and LaTeX without the need to resort to another program.

Here are some of the reasons why I like and use Emacs:

  • Windows and Frames: Emacs is capable of splitting the screen into multiple portions, even on a terminal! In a Windowing system, it is capable of displaying multiple screens too. Emacs' concept of screen-splitting came much before the advent of GUI, and it calls the split portions as "Windows", which conflicts with the contemporary usage of the term. Multiple screens are each known as a "Frame".
  • Multiple Open Files: Vi being a single screen editor can let you work only on a single file at a time. Emacs lets you work with practically as many files as you wish to and even display them juxtaposed side-by-side. This feature along with the above mentioned one is a tremendously strong argument in favor of Emacs.
  • Multiple Modes: Emacs can adapt it's behavior according to the kind of file you are editing. It accomplishes this through "Major Modes" that are extensions to the main editor. For example, the C++ major mode can automatically indent code for you. It can perform C++ specific operations on regions of text, like commenting/uncommenting, macro expansion etc. Emacs can load the appropriate major mode simply on the basis of file extension but you can always make it load another mode if your file extension is not recognized or you deliberately want another mode.
  • IDE functionality: Emacs can function as a highly capable IDE with sophisticated features such as syntax highlighting, code browsing, code completion, context-sensitive help look-up, compilation and debugging etc.
  • Concurrence Handling: Emacs maintains it's own copy of the file you are working on and changes the original file only when you do a save. It also keeps track of whether the file you are editing has been changed on the disk by someone else. If someone did change the original, Emacs informs you of this when you are doing a save. You can then choose to over-write the original, load the changed version of the original (and loose your changes) or save the file to some temporary location while you sort out the differences with the original.
These features certainly make Emacs highly desirable but there's more. Expression of thoughts. I find Emacs an extremely supportive platform for heavy-duty text editing, be it for authoring or development. The editor completely disappears from the mind-frame once you become fluent with it. There are no peculiarities or quirks to bear with. It does almost whatever you need Emacs to do, whether it be through core functionality or some extension. The only things that Emacs can't do are those that you'd never expect a text-editor to do.

It keeps up with the Unix tradition of productivity through co-operation of tools that do specific functions and do them well. Emacs acts as a glue application (much like Perl is a glue language) for all these tools. The advantage that I get is that for whatever I do, my interface to the computer remains uniform, while I am not restricted in choice unlike the IDE's that each come with their own compiler, debugger, editor etc. Nor am I restricted in functionality like most other Text Editors.

Vi proponents say that Emacs can only be operated by Aliens, that it's bloat-ware, that it requires more than 10 fingers to operate etc. The truth is that Emacs is a much more intuitive editor than Vi. It is much more functional than Vi and it requires less keystrokes than Vi to do most jobs. Let me tackle these jibes in succession.

Emacs is not for Aliens
My single greatest point of disagreement with Vi is that it has two modes for working in. In one mode (Command Mode) you can only give editing commands but not write any text. In the other mode (Insert Mode) you can only write and not issue any commands. People say that this is intuitive editing since people either type or give commands at the same time. Huh, and what about the fact that you have to press Esc every time you have to go into command mode and i (or I, or A, or a, or o, or O...) to go into insert mode. This "feature" is a hangover from ed that was perhaps the first text editor in Unix and was a very rudimentary editor with just about as much functionality as today's echo command on modern terminals. I don't know if that's not a concept for aliens, what is? The commands in Vi are not any more intuitive than they are in Emacs. True, Ctrl+x Ctrl+s is somewhat more cryptic than :w but practically every command in Emacs can be accessed through Alt+x <command-name> and you get Tab completion to boot. You really don't have to memorize the commands. By the way, Alt+x save-buffer is an alternate command for saving in Emacs. And you need not remember the -buffer part. It's completed for you automatically. When you have to do Alt+x compile to compile and Alt+x debug to debug, that's called intuitive.

Emacs is not bloat-ware:
Vi makes you revert to the shell for every single thing that is not text-editing. It's still OK on the terminal. But what about GUI? How much functionality are you ready to sacrifice to stick to a simple text editor? Would you really like to stay stuck with the command-line (this is different from using a lot of keyboard)? I have made my choice. Vi proponents call this pathetic lack of functionality "lean design" keeping with the Unix design philosophy of tools that do a task and do it well. To achieve maximum productivity, you have to have a means of bringing those tools together to work in tandem. On the command-line you have pipes and I/O redirection, for example. And you have Emacs.

Bloat-ware is software that contains too much functionality within it to be ever used completely. All those extra features add to the complexity of the software and make it bulky to launch and run. Emacs is not bulky. It doesn't carry much functionality within itself. The core of Emacs is still more complex than Vi but that's because of features that are truly essential and frequently used like the option of having multiple open buffers and window splitting. Emacs derives it's functionality from extensions that are written for it. These extensions are not part of Emacs and they are loaded only when needed.

Emacs doesn't require more than 10 fingers to work on
On the contrary, Vi seems to be the one that's most disruptive to the flow of keystrokes while working. Emacs keystrokes are much easier than Vi and they can mostly be performed with one hand. Take the most basic example - saving:

Vi: :w
Emacs: Ctrl+x Ctrl+s
Well, you see, the Emacs command for saving is much simpler. Whoa! you say. It's so much more long than the Vi command! Look more carefully. Vi requires you to type :w. This involves three keys - Shift + ; (to get a ':') + w. And you have to press Enter after that. Moreover, : and w are spaced widely apart on the keyboard. It is impossible to execute this combination with a single hand. Moreover, if you were writing text just before saving, you'll also have to press Esc to get into command mode. In Emacs the same operation requires you to hold down Ctrl and press x and s in succession. All three keys are conveniently placed close to each other and you can quickly execute this combination with just one hand - a thumb and two fingers to be precise!. So, it's really like:
Vi: Esc+Shift+;+w+Enter (5 keys)
Emacs: Ctrl+(xs) (3 keys)

This is just one example - one of the most basic. The story for most other commands is similar. My point is that Emacs commands are definitely not more difficult to issue than Vi.

Start working at the speed of thought

To get yourself started with computing at the speed of thought, you need more than a Text Editor. As I mentioned before, you have to look out for tools that break your tasks down into neat logical steps instead of cramming everything into one big process. Fortunately, for most of the common applications, there are such tools available. As an excellent example of this philosophy is LaTeX for document preparation. It breaks down the task of writing a document into three steps:

  1. Writing the document in structural markup. All you do here is write your stuff in plain text, specifying structures like sections, chapters and figures through simple markup.
  2. Formatting the matter. This is something that LaTeX does automatically on the basis of rules developed from years' of professional typesetting experience. You need not bother about fonts and spacing etc. and still get the most professional-looking output. There are, of course, ways to override some formatting if LaTeX's rules are inadequate to handle some peculiar situation.
  3. The final step is getting output in a format you desire. You can get your document in output formats like Postscript (keeps Laser Printers happy), PDF, HTML etc. depending on your requirements.
You need not bother about the latter two tasks unless you are finished with the first. That is where you put your thoughts on some medium and you need not worry about anything else while doing so. Formatting and output take just a few seconds even for a long document spanning scores of pages. Compare that to how much work you have to do in your WYSIWYG Word Processor to try and make your document look nice.

Emacs works in tandem with such tools in a most seamless manner to give you an unprecedented level of productivity and speed. Use all that extra time to SlashDot or do your stuff. It's true that there's a learning curve with Emacs but it's scalable. You need not be a Computer Engineer for that and the payoff is immense. Alternatively you can be a cribbing frizzle-nerved Vi user or stick with your Lord of the WPs - MS Word - and be ever confined to darkness.



© 2002 - 2004 Tahir Hashmi. Unauthorized copying, alteration and redistribution in any media is prohibited, except where explicitly stated as being distributed under the OpenContent License (OPL). Last updated: 21 February, 2021. Update Log. Personal Email: tahir AT tahir.ws [PGP Key: ASCII, Binary]; code_martial AT softhome.net [PGP Key: ASCII, Binary] IM: Yahoo! Messenger [tn_hashmi]