Top ten essential Emacs tips

The kill/yank names rub me the wrong way because where "cut and paste" suggest X-acto knives and glue sticks to me, that is, editing text on paper, there's no metaphoric grouping between "kill" and "yank". It also makes expressing the act of copying awkward. Copying is called "kill-ring-save", which is a kind of terse "kill-it-but-don't-actually-kill- it-just-copy-it-as-if-you-did". It further breaks down any metaphoric concept tying them together.

I'm not arguing that "copy/cut/paste" are better terms because they're already used by most people, but rather because they collectively express the operations in terms of an existing, analogous, and likely familiar idea. (I think the "ring" part of it is perfect, though.)

I used vi (vim) for about five years, before switching to emacs (gnu emacs), which I've used for about two. They're both excellent text editors, but are clearly optimized for different things, and have tremendous differences in interface, extensibility, and culture.

The big advantage for Emacs lies in being a sort of Lisp virtual machine. It's extensible enough to be nearly an OS in its own right (certainly a "desktop environment" or whatever), and has decades of extensions already available for it. Where vi(m) has two fundamental modes (with replace being a submode of insert, I suppose), emacs has modes specific to most tasks -- if you want a mode that integrates with an external Common Lisp (slime), OCaml (tuareg), or Ruby (ruby-mode), it's there. This doesn't just mean syntax highlighting and indenting, it means more abstract things like being able to insert the type signature for a Haskell function under the cursor, jump to the definition of an object's superclass, or check/edit/archive your email. (For a really good example, check out this screencast of Marco Baringer using Slime: http://common-lisp.net/~mbaringer/slime.torrent ) Emacs Lisp is not the greatest as Lisp implementations / dialects go, but it has a lot of advantages for extending an editor compared to something like Python or Perl. (I have a suspicion Smalltalk or Forth would work well, though.)

I know that vim is extensible, but typically you process a region by typing :%!some_cmd to pipe it back and forth; most integration between vim and external programs that I've observed has been at the level of piping text (in the quintessentially Unixy way). This loses a lot of deeper context that could better tie things together.

The main strength of vi, I think, is in its ubiquity. While I use emacs to do most things, I also have a heavily customized environment that I carry around with me. (It's under version control, etc.) I can be extremely productive with it, once I've moved in, but vi is available everywhere. I'm talking about a basic vi (nvi?) with one level of undo and no syntax highlighting, perhaps, but it's still pretty good for editing text, particularly if you're a touch-typist and the interface has become second nature. It edits text. It doesn't tie things together into one harmonious environment, but it edits text, and it's really efficient once you know it.

For what its worth, there's an editor called "mg" which has the default emacs keyboard config out of the box, but is not really very programmable. While I'm very familiar with the basic keyboard controls, it feels crippled to me. I use it while doing computer setup stuff, because it's in the default OpenBSD install, and it's a decent pager, but it's really not the same.

Anyway, that's my experience with each. Emacs seems far more powerful in the long run, but it takes quite a bit more time to learn to use it to anywhere near its full capacity, and doing so will rely on carrying around your configuration. (It also has a relatively alien culture and vocabulary, which takes some getting used to.) Vi does what it does everywhere, but cannot grow indefinitely to fit your needs. It's focused on just being a good text editor, rather than a full environment. If you're talking years, though, I would definitely give emacs a shot.

(Incidentally, I think emacs is quite reasonable under the Dvorak keyboard layout (better than qwerty, I think), while vi feels far more awkward. The hjkl keys get scattered badly, for one thing. That, a growing fascination with Lisp, and being utterly blown away by the Slime screencast were why I ultimately switched.)

If either were optimal in every case, this debate would be settled by now. Yet what matters here, more so than tiny idiosyncrasies in each, is the overarching philosophy each editor has, and whether that maps to your mode of thinking. I admit this is a dubious answer: our thinking can be restricted by choices we made early on and got used to, but never attempted to improve upon. If you do attempt to explore beyond what you have tried, by definition you run the chance of regretting lost time in the case where you find a better way of doing something. But this is a blessing in disguise anyways. I try not to let such fear (or even complacency, as the case may be) keep me from trying further things unless -- and this is a big, subjective caveat -- I feel as though I stand nothing to gain from pursuing it. The choice of text editor seems about on par with the choice of any other programming tool, such as a language or version control system. Not all of them are created equally, except in the technical sense (as in, e.g., Turing equivalence) that, at least in the limit, you can achieve the same things with one tool as another. Any may be more productive than another, but this is per person, situation, and preference. The only way to know for certain is to invest time (a precious resource) into learning all that you can.

I feel weird making such claims. For instance, I have very strong opinions over programming languages (though I do try to learn as many different modes of thinking -- in this context, languages -- as I can), yet with text editors I don't feel like I've been stuck with vim as an accident of history. I genuinely prefer its mode of thinking, despite not becoming an expert in Emacs before making a decision (since doing so is quite impractical). I also feel the flimsiness of the reply "depends; try both and see". To cut to the chase, luckily we have decades of flamewars to draw upon -- or, at least, the general consensus of the philosophy of either editor. Choose wisely:

Vim: modal editing; small, orthogonal commands that can be composed into more elaborate forms; "do one thing and do it well" philosophy, so the main function is as a text editor and there is less concern (except via plugins in its admittedly esoteric extension language) about performing other programmatic tasks not directly related to editing text.

Emacs: "Everything at reach" philosophy, be it text-editing or access to a REPL, browser, email client, Tetris, etc.; larger set of commands (it's like a CISC to vim's RISC); elisp is a much better extension language; no mode switching, which then requires more key-chording.

Whichever sounds nicer, you should probably go with, unless you have the time to dedicate to both -- even a little bit of working in either can help you get a feel for them. If you don't, they honestly accomplish so much of the same sort of tasks in their respective ways that neither is clearly better than the other (except to their proponents -- did I mention vim is better? ;) ). Which is encouraging, I think, because it buys you a degree of freedom to use their general philosophies as a grounds for a decision, rather than having to teach yourself every detail about each editor. You won't be at a terrible loss, whichever you choose.

i think it won't be so easy to compare because it's easy to noob vim. i know people that have been using it for a while yet still think of command mode as a "secondary" mode

I've found I don't miss much from Perl 5. The only things I've found really funny are backslashing special operators that you don't in Perl, like \( \| and \{. Oh, and \s- for whitespace is very weird to me. And there's no \d. And instead of $1 in the replacement, you do \1. Once I got used to it, I found them very close to each other, at least for everything I do.

Like Steve Yegge (in Effective Emacs), I alias query-replace-regexp and use it every day. Lots of other good tips and pointers to interesting topics there.

http://steve.yegge.googlepages.com/effective-emacs

M-x re-builder can help you learn them interactively, though.