Emacs My Way

The very first thing I did after switching to Emacs was to rebind most frequently used keys to something sane. The next thing was to make the functions themselves sane - IIRC the first command I wrote was "comment-or-uncomment-region-or-line".

My emacs config is about 4k lines of my own code at this point, very little of which implements anything by itself. It's full of customize-options, hooks and defadvices, eval-when-loads and similar things, which make Emacs into my editor. If I had to learn some defaults I couldn't change I would just use some IDE or another editor.

After 3 or so years of using Vim heavily I started hit the limit of what can be done with defaults, simple options adjustions and even plugins. I honestly tried to use Vimscript, but I couldn't bring myself to do this for real. I knew some Scheme then, so I wasn't afraid of Lisps. I switched and I immediately started implementing things I wished I had implemented months earlier in Vim. My Vim config was ~700 loc and it had only a few custom commands defined in it after 3 years. As I mentioned in another comment my emacs config is ~4k loc now and defines a multitude of advices, hooks and plain commands after half a year. It grows almost every day and what's most important is that coding to Emacs APIs in ELisp gives me much more pleasure than coding in Vimscript.

Lastly, modality - somehow I'm not missing it. It's not that I've seen the light and now think that modal editors are an abomination, but I came to appreciate modeless-by-default model of editing. Emacs ofers many ways to enter modal mode, so when I felt that modal interface would be better for something I just coded it so it's modal.

In short - if you're a happy Vim user who doesn't feel the need to write your own Vimscript (or you're happy with Vimscript!) then I see no reason to switch (maybe org-mode or something, but that's a very specific case). But if you thought at some point that you'd like to code up something in your editor but didn't because it was too much of a PITA then give Emacs a try.

This is especially true in the case of a Vim user, because, unlike most editors (Sublime Text especially), Vim is roughly comparable with Emacs in terms of raw editing power. Each is about as powerful as the other, in most respects, and each has borrowed concepts from the other over time -- some Emacs modes are "modeful" in the Vim sense, in that you might, for example, press 'e' to enable editing in an Occur (regexp search across file) results buffer, and C-c C-c (control-C twice) to switch back to browsing mode; in the other direction, I hear Vim has windows now, as well as buffers.

The difference between Emacs and Vim isn't so much one of basic capability as of perspective on the world; Vim is (more or less) the quintessential Unix editor, very lightweight and deriving most of its power from the broad range of tools provided by the platform. Emacs, on the other hand, is more or less a virtual Lisp machine with a text editor built on top of it, and while many of its capabilities work in concert with external programs, it is as much as possible designed to behave independently of whatever platform it happens to be running on. The cavil that "Emacs is a great operating system which just needs a good text editor" is, as with many cavils, not entirely devoid of truth; rms has I think never stopped grieving for the MIT AI Lab and its Lisp machines, and a lot of the early design decisions that went into GNU Emacs were driven, I think, by a desire that it should offer at least a broadly similar environment -- turning a Unix box into a Lisp machine in spite of itself, if you will. (After a few years using Emacs, I can understand what makes that a desirable result, too.)

But, overall, either editor can do anything the other can, to the extent that the editor war has no clear winner; if you use the tools you're comfortable with, and get as good at using them as you can, then it's hard to go too far wrong.

On the other hand: Emacs has Tramp, which is far and away the best tool available for transparent remote editing. If you can get to a file by any means more immediate than emailing it back and forth, you can open it in Emacs, edit it, and write it back, with only as much additional effort as is required to identify the host and authenticate for whatever protocol exposes the file. And, unlike FUSE, it works identically on every platform where Emacs itself compiles, which matters to me because I use all of Linux, OS X, and Windows, for both work and play.

Better still, Tramp ties into Emacs' built-in shell, so that you can, for example, 'cd /host:/path/to/some/directory' and run shell commands there, copy files back and forth between local and remote directories or from one remote host to another, so forth and so on, and have everything behave exactly as you'd expect. For someone like me, who spent years sshing hither and yon, opening another xterm to scp something across without having to drop a remote shell, et cetera and so forth, Tramp, and especially Tramp + Eshell, amounts to a revelation. I'd never used anything like it; I'd never imagined anything close.

If what you're using right now satisfies your needs, then I wouldn't recommend Tramp and Eshell as a reason to switch. But if your needs change, to a point where what you're using right now can't live up to them, it's an option worth keeping in mind.

I'll refrain from making the obvious Star Trek reference, and instead use this meta-reference.

Sublime has plugins, but it's nothing compared to the Emacs ecosystem. I can edit code in one pane, manage my git repository in another, have a terminal to run tests in a third pane, chat with a co-worker with Jabber in another, and look up documentation in a browser (w3m) in yet another pane. The merge conflict resolution capabilities in Emacs are also pretty excellent. I'd say they're at least on par with Vim's excellent Fugitive plugin.

Org mode is a thing of beauty. You can write notes (and enable spell checking in the buffer), create TODO lists, spreadsheets, calendars, handle time tracking, and even embed executable snippets from various languages. The coolest Org mode story I've heard is about Avdi Grimm. He wrote a Ruby book in Org mode and embedded his code right in it. With a single Emacs command he could extract the code from the book and run specs against it, and also package the whole thing up as an ebook.

The learning curve doesn't have to be as brutal as depicted in the blog post. I've only been using Emacs for 4-5 months, and I'm already very efficient with it. I've changed a lot of the keybindings to match what I'm already familiar with, so I didn't learn Emacs as much as I made Emacs learn me.

I used Sublime for years before my switch to Emacs (with a 3 month layover in Vim Land). Sublime is really easy to use, and I still recommend it for designers who write a bit of code, people new to programming, and people who just aren't interested in learning new tools. That said, I spend 90% of my time writing code, and it's great to have an editor that can trivially be made to do whatever I want it to.