Subscribe to Rahul's Blog        RSS Feed

Moving to GNU Emacs

Icon 2 Comments
After being a Vim lover for about 4 years, I've switched sides to Emacs. Before I make this into a personal post about why I think Emacs is great and so forth, a better way to go about this would be an objective view from both sides of the holy-editor war.

A bit of history
I got introduced to Vim from various discussion sites I visit including Reddit and Slashdot. It always had a mysterious aura about it promising unlimited productivity once you got past the initial learning curve. When I finally did manage to ditch gEdit and Kate, I was not disappointed. I devoured endless tips on becoming more productive with Vim and ended up learning a handful on a lot of things. The modal editing interface and the speed at which it enabled edits was second to none. I slowly managed to configure my vimrc to my liking, put in some scripts (plugins) like NERDTree, TagList, BufferExplorer, my goto color schemes - desert and oceandeep and the result was a very productive development environment.

Somewhere down the line I got interested in the Lisp family of languages, especially Common Lisp, and SLIME was the only development environment which could hold its own against IDE's of other languages. This was my first introduction to Emacs and I found it to be extremely powerful but not worth the effort to switch completely since the vi keybindings had been burnt into my fingers.

What made me switch
Surprisingly my first true usage of an emacsen was Jasspa Microemacs. It is a fairly good distribution and but did not blow my mind enough that I would give up on Vim and my customizations. However I still continued to use it on some test systems, but only with the CUA keybindings. I found its features compelling enough to warrant usage even if I did not use its Emacs like modes.

I had always been a fan of minimal web browsers like Dillo, Elinks and Lynx, something which can show me hyperlinked text without bothering with fancy effects and sometimes even images. Time and again people recommended w3m-emacs integration to me. This coupled with SLIME made me start reading about Emacs which became a fascinating journey through learning about the various modes inside the default full package. It became clear to me that the kitchen sink approach might suit me a lot since my Vim configuration was going in that direction anyways. And thus began my baby steps in Emacs.

I thought of using the Viper mode in the beginning to ease my entry into the Emacs but I soon realized I would be better off learning the Emacs-way since its assumed in almost all manuals and forums. The confusion becomes a bit much if you stay too long in a Vi like mode inside Emacs though I guess this is an individual choice.

How I use my Emacs environment
I like Emacs for the one reason some people loathe it - the kitchen sink approach, and I mean this in a good way. In my daily workflow, I get through the day mostly working in my GNU Emacs and some Iceweasel (I use Debian). I develop my scripts in the CPerl-Mode, read my mail through Gnus over IMAP, do most web browsing through emacs-w3m and make heavy use of Dired for file operations.

What really pleased me was that I could do all this and more through a uniform interface, all of which was running on top of an abstract (e)Lisp machine of sorts. Despite the endless choices available to do a task inside Emacs, I managed to stick with some of the modes that appealed to me. I like to make notes and track progress as plaintext in an outline fashion and the outline-mode suited me perfectly because of its ease of use. For my modest requirements, Org-Mode and Allout seemed to be something that I should explore later. I also heavily use the PCL-CVS mode which has almost made TkCVS redundant for me.

Why Vim is still cool
Vim and the vi model is a better fit if you are a rapid writer and frequent editor. Some people pen down their thoughts rapidly and then visit it again to revise it multiple times till they get something that they are happy with. This is seen often if you adapt parts of a codebase from another similar project of yours and then change it to fit into your current project. Vim in its normal mode gives you a great set of commands combinations to rapidly support this model of growing your code. Emacs on the other hand, while offering a very similar command set to work with text, has lengthier keystroke combinations to achieve the same or an execute command through its M-x interface which is no doubt lengthier than their vi/Vim equivalents. Of course remapping your favorite commands in either editor negates this point to a large degree, but the general argument still holds.

Vim also has a smaller number of contributers with Bram Moolenaar acting as its chief chef. This leads to some interesting evolutionary design of features as opposed to Emacs which has a larger contributer base. While Emacs tends to be almost anything to almost everyone for a large number of reasons including the varying development habits of its core members, Vim growth closely reflects the thought process of Bram which I daresay sometimes leads to more integrity in the soul of the project. This maps directly to Fred Brooks' Mythical Man Month's chapter on conceptual integrity which states than a single (or a small number) chief architect can lead to more user-friendly software.

Why Emacs is a better choice for me
My primary occupation is to write Perl code and I occasionally dabble in Common Lisp. In doing so, my personal way of coding starts off with writing what I would build as a series of outlined bullets. I then elaborate upon them till I have a fair idea of what exactly I am going to be putting in as code. This is followed by high level module and subroutine stubs which I fill in with details once I've decided upon my abstraction's contract. I frequently take long pauses to think about the next bunch of statements I am going to type in. Except for looking up calling parameters, I seem to code down my thoughts fairly well but not before thinking a good deal beforehand.

In this style of development, I seldom feel the need to enter a quick type-edit-fix-repeat cycle. What I do need though, is a development environment that allows me to capture the details as an outline, my documentation lookups inside the editor and keeping me hooked onto the environment long enough that I start thinking about the next bunch of statements. And for all this, Emacs seems to be a good fit.

I also am a heavy user of desktop applications (read non-webified), primarily switching through my mailbox, browser, calendar, shell, dairy and editor routinely. After the Emacs keybindings were burnt into my fingers, it became effortless to switch between these as major modes inside Emacs itself, carrying over both my keybindings and my unified interface. Lastly, being a starter in the Lisp world, I find editing ELisp code more intuitive than VimScript.

How to make up your mind about this
While this boils down to a matter of taste, there are some helpful pointers to make this choice easier - the primary one being availability. If you are a system or network administrator who tinkers with a lot of *nix systems, a vi variant is almost always available. Emacs does not come installed by default on a lot of systems and the chances of you finding an emacsen with the modes you prefer is still lesser.

Emacs on the other hand is the editor of choice if you dabble in many programming languages and are looking for more than an efficient editor. It is also the defacto IDE for the Lisp family of programming languages.

If you like separate specialized applications for various tasks, Vim is a more attractive option to start with. While Emacs is a perfectly capable editing application, you'll get the most benefit out of it if you use it string together the applications in your workflow. This is especially true if you are fond of console based applications because Emacs treats everything as a collection of text with properties.

Some tips for a newbie Emacs user
One of the first things I do while customizing any editor is to replace tabs by spaces. To achieve the same, add the following snippet to your init.el file.
(setq-default indent-tabs-mode nil)

There are two major modes offered with GNU Emacs for Perl development. The one containing a larger set of features is the CPerl mode which is not turned on by default. If you wish to directly go into Cperl mode whenever editing a Perl file, the following snippet makes this mode as default.
(defalias 'perl-mode 'cperl-mode)

Emacs comes with three built-in mail clients - RMail, Gnus and MH-E (a frontend to RAND Corp. MH program). Mew and Wanderlust are two respected mail clients that have to be installed separately. While choosing between them is a matter of personal preference, my opinionated advice is this - if you're using POP to access your Inbox, RMail is good enough. If your protocol choice is IMAP, choose Gnus, Mew or Wanderlust. I personally chose Gnus and integrated BBDB as my contact management handler. If you plan to do the same, adding the following to your .gnus would hook BBDB into your Gnus startup.
(add-hook 'gnus-startup-hook 'bbdb-insinuate-gnus)

It is easy to get lost in the vast capabilities of Emacs modes and what all applications they can replace in your workflow, but I suggest to tackle these one at a time. Start using Emacs as a text editor first and gradually pick up features which make it a development environment. This will initially be frustrating, but realize that this is normal. Once you get the hang of how Emacs works with text, move into other modes like Dired (Directory explorer). Start integrating these modes slowly in your workflow and you will soon be able to navigate effortlessly between them. As with any application with capabilities as vast as Emacs, a point bears repeating - it will take time, have patience.

Some further references
Besides the Emacs manual and tutorial bundled with the default installation of GNU Emacs, there are numerous help sites to learn more about Emacs.

Emacs Wiki - A large collection of contributed documentation by users of GNU Emacs and XEmacs. This should be the first place to look for further information after the manual.

comp.emacs usenet group - A discussion group about Emacs, good for searching on more arcane topics when help is not available elsewhere.

emacs-fu - A great blog featuring specific tutorials targeting users who wish to do more with Emacs.

2 Comments On This Entry

Page 1 of 1


23 May 2011 - 09:23 AM
Apostasy. Watch your back. :)

(I'm pretty set on vi - I typically have a window open for each source file I'm editing, and another for compiling/running. On my machine, which has a nice big screen, that lets me see three source files and compiler output/running results at the same time. This is a Good Thing. Some day I might give Emacs a real try, but it's really too much like Word for my taste - far too many bells and whistles, and you can't do anything unless you already know how to do it. vi works the Unix Way: a simple set of options which combine productively, instead of a massive set of complex commands which have to be learned uniquely.)


23 May 2011 - 10:10 AM
Welcome to the dark side! I've been an Emacs user for about 2 years. Never could really tolerate Vim or get used to it, even before I tried Emacs. I really enjoyed this post because you have exactly the same thoughts that I do: I like the kitchen sink approach in Emacs, and Emacs suits *my* style but not necessarily everyone else's style. People get caught up in which editor is objectively better, but they're both good for different people and different purposes. It isn't about which one is better but which one is better for you.

Welcome to the Emacs world.
Page 1 of 1

Trackbacks for this entry [ Trackback URL ]

Tech from Pearltrees

Tracked on Jun 23 2012 11:04 AM

Search My Blog

1 user(s) viewing

1 Guests
0 member(s)
0 anonymous member(s)