How to Learn Emacs: A Hand-drawn One-pager for Beginners

Over the years, I've used Perl, PHP, SQL, shell scripts, Python, Tcl, C, Erlang, HTML, Javascript, Java, Ruby, LaTeX, DocBook and other flavors of XML, nroff (man pages), CSS, and probably other stuff I'm forgetting. Emacs always comes through with pretty good support and a familiar environment, even if the particular language is a new one. I'm confident that it will continue to do so in the future.

So, vim, not vi, is really what you should be comparing emacs to. Vim is far more feature rich than vi, and has plugins that allow shell integration. So shell integration is not a good enough reason to prefer emacs over vim, as vim has it too. Further, emacs' shell integration really isn't that great (contrary to many claims I've heard in the past). It's pretty buggy, with random screen corruption and many keys not working as expected.

That said, there some great reasons to prefer emacs over vim (and I say this as a vim user of about 20 years who's in the process of switching over to emacs).

The first reason is eLisp. I love Scheme and Common Lisp, and much prefer to have an editor that's scriptable in a Lisp dialect. Yes, here too vim isn't quite stuck with vimScript only. It is possible to script vim in other languages (like mzScheme/Racket, Python, Ruby, and Lua). But 99.9% of vim scripts are written in vimScript, for reasons that I guess at elsewhere.[0] There are maybe one or two vim scripts written in Python, but I've never seen one written in mzScheme or Racket (or Ruby or Lua, for that matter). So, practically speaking, the vim user is stuck with vimScript after all. That's not the case with emacs, where the entire community scripts in eLisp.

The second reason is the tight integration of many applications with emacs. You could read your email in emacs, browse the web through emacs, read RSS news feeds through emacs, etc. And when you do this, you bring the entire power of emacs to bear in customizing and interacting with these embedded applications. As a result, much of your environment becomes easily extensible and customizable through eLisp, and automating repetative or complex tasks that you perform in these applications becomes much easier as well. Yes, you might be able to do something similar in your standalone browser through Javascript, or maybe your standalone mail reader might be scriptable and extendable to a certain extent, in some language or other. But if you choose the standalone application path, you're going to wind up with a very fragmented ecosystem, programmed in a half dozen or more languages, and not very tightly integrated. With emacs, everything is tightly integrated and programmed/exteneded/controlled through eLisp.

The third reason is org-mode. Here again, vim is not completely without it, as it has some plugins inspired by org-mode. But from what I've heard, they're a far cry in capability from what org-mode offers in emacs. That said, I'm only starting to dip my toes in to org-mode in emacs, and have never tried the org-mode-like plugins in vim, so I'll stop with the comparisons here. But I will just quickly mention that I've heard of people switching to emacs just for org-mode, and after using org-mode a little, I can understand why.

The fourth reason is Guile. In the not-so-distant future, Guile will bring emacs scriptability to the next level. Many things that were painful or impossible to accomplish with emacs built on C and eLisp will be able to be accomplished with emacs built on Guile. (See here[1] for details) That said, eLisp is not going away, and is not going to be fully replaced by Guile.

The fifth reason is evil mode. Emacs can do a fair emulation of vim's core functionality. Evil mode can go a long way towards making a vim user comfortable in emacs -- and in letting emacs users edit more efficiently using vim-like keybindings. (There are probably vim plugins that try to do something similar for vim, but I doubt they do much beyond providing a handful of emacs-like movement keys.) With evil mode, you get the best of both worlds.

There are probably other good reasons to prefer emacs to vim. But those are the ones I can think of off the top of my head. There are also good reasons to prefer vim to emacs. I personally find that vim provides a more usable experience out of the box, without too much hacking. But I may be a bit biassed here. This is actually an area where both editors could stand a lot of improvement, as both do require some hacking around to get the editors to a reasonably usable state. Yes, you could do basic editing in both out of the box, but really not much more (unless you're a masochist, or RMS -- who supposedly prefers vanilla emacs).

There's also less to learn and tweak in vim (simply because it doesn't have a ton of applications that can be integrated in to it -- you are basically going to be learning and tweaking its editing capabilities only). So in that sense, learning and tweaking vim is easier than learning and tweaking emacs.. or at least you'll probably spend less time doing so. Emacs is a supermassive black hole of infinite customizability, while vim is more like a regular black hole of editing-oriented flexibility.

I'd continue making an exhaustive comparison of the two editors, but this is starting to get kind of long.. In sum, they are both great and powerful editors, and you would not go far wrong in choosing either. For me, the balance has tipped in emacs' favor, but I would not begrudge anyone for choosing vim.

Update: Yes, SLIME! How could I forget SLIME? SLIME was one of the first things that attracted me to emacs. Now I'm actually much more interested in programming Scheme than Common Lisp (at which SLIME is primarily aimed at). But emacs also supposedly has some nice REPL integration with Scheme as well, including via SLIME.[2][3] It also has parens mode, which makes editing sexp's so much easier than they would be on vim (to my knowledge). That said, vim also has some REPL integration plugins, like Nekthuth.[4] They're not nearly as powerful or well integrated as SLIME, however.

[0] - https://news.ycombinator.com/item?id=5681534

[1] - http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg006...

[2] - http://www.emacswiki.org/emacs-en/Scheme

[3] - http://www.doof.me.uk/2010/12/12/using-slime-with-chicken-sc...

[4] - http://www.nekthuth.com/

And in most programs (especially vim) I'm only ever a C-z away from a shell I can use to test code, run curl, etc :)

It just makes more sense to me to host my text editor in my shell, not the other way around. But then, I guess Emacs isn't really a text editor so much as a development environment, complete with integrated shell.

http://blog.vivekhaldar.com/post/3996068979/the-levels-of-em...

http://my.opera.com/mulander/blog/2009/02/17/how-emacs-keeps...

Vi(m) will be there.

This means that you often don't have the luxury of installing anything on the machine you find yourself on. You might find yourself on a small Linux-based router that only has busybox on it. This is the case for many resource-starved VPS' and other small Linux installs as well. Busybox comes with vi, but not with emacs (or even vim). If a sysadmin finds himself on one of these, he simply has to make do with what he has. He may not have the time, or an internet connection, or the authority to install anything at all. So familiarity with vi in these circumstances is essential.

On very few machines will the situation be reversed: with emacs or mg available and vi not (I have never run in to such a case). So a sysadmin has little incentive to learn or install emacs.

As for mg, even if you could install it, I'm really not sure what it would buy you over vanilla vi. In the kinds of resource-starved environments where you'd actually prefer mg over emacs, you wouldn't want to spend a lot of time editing anything. A quick in and out edit should really be all you could reasonably be expected to do in such a situation... and that could probably be done equally well with either mg or vi.

oh no, mg is pretty crappy. I use a lot of emacs features and the ones I just need on that file are usually not available.

If I need to choose between mg and vim I'll always use vim, it's far superior than any of these cheap emacs clones.

Use a real Emacs or use Vim... that's it.

EDIT: gnosis mentioned why https://news.ycombinator.com/item?id=5730714 . i've only come across those cases a handful of times though

I'm using my own color scheme (example, https://img-fotki.yandex.ru/get/3314/ottalex.5/0_23992_5fbf7...). If you want, you can grab my configs from https://github.com/alexott/emacs-configs/ (mac os x-specific parts in rc/emacs-rc-local-flash.el)

It's basically a slightly tweaked version of color-theme-zenburn with rainbow-delimiters mode, (setq font-lock-maximum-decoration t), and modeline tweaks from http://emacs-fu.blogspot.com/2011/08/customizing-mode-line.h...

My Emacs: http://i.imgur.com/SNTZL6i.png

At first, Emacs font rendering felt weird to me, but some tweaking made it look slick. I use the ir-black theme with the Monaco for powerline font. Here's my config: https://github.com/mgill25/dotfiles/blob/master/emacs

Looks like you want global-linum-mode to get line numbering. then to remove tool, menu and scroll bars do (tool-bar-mode -1) (menu-bar-mode -1) (scroll-bar-mode -1)

I thought pretty much the same, until I recompiled it using Athena widgets, which brought it back to its intended glory.

I think the final result looks rather good: http://jelv.is/emacs-blackboard.png and http://jelv.is/emacs-demo.png.

I for one would be interested to see how your approach pans out as an accomplished design.

I have a mental image of a stack of buffers being shown as a sheaf of overlapping 'cards'...

† However it doesn't really pay to customise the basic key bindings away from the defaults too much, because all the major & minor modes have key bindings carefully thought out to be consistent with the defaults.

The default emacs keybindings strike me as particularly insane and not suitable for productivity or long term wrist health, but I use them because I don't want to go through every different mode as well as tmux, and my wm to figure out which bindings are going to clash.

I know that I should do it, but I'm lazy. If anybody has a really thought out set of bindings that are optimized for minimizing chords and sequence length as well as conflicts I would love to know about it.

What I'd really like is a scientific project to come up with a control scheme for the OS and emacs that maximizes keyboard efficiency.

But I think a lot if not most of HN are actually SublimeText fans, not vim fans.

For Vim users the keybindings are essential, but for most the scripts aren't that important, that's why other editors can seduce them by offering vi keybindings. But an Emacs user shivers at the thought of losing all their elisp.

(Note: Vim user)

I use Tmux for managing multiple sessions, so I generally have a lot of Vim sessions going at one time. Emacs is just another session for me, so it's a regular part of my workflow to switch back and forth.

Emacs will tell you it's an "extensible, customizable, self-documenting real-time display editor." That's quite a mouthful, especially if all you had in mind was to edit some text. And I say this with all the nostalgic affection of a long-time emacs user.

I wanted something I could use over SSH, even on really bad connections such as mobile. vim works great over poor connections.

I barely use plugins, and seldom configure syntax highlighting.

On the desktop I may use vim, but tend to use Sublime Text for everything. Go, Java, HTML, CSS, JavaScript (node and browser)... Sublime Text serves me really well and works the way I want to work. Before Sublime Text I was 100% vim, after Sublime Text I'm 80/20 ST/vim.

But for whenever there isn't ST, vim is always there.

While technically Emacs users and advocates are right, they lose big time in "marketing" or "public relations". I don't really think that this is going to be fixed.

When my emacs starts, it checks things like the size of the screen and what windowing system is running and picks fonts and sizes accordingly.

The big selling point of emacs, really, is that it's command driven - and you can go write the commands yourself. All the boring little tasks that you do while writing normally? Changing variable names in multiple places, if you have largely formal constructs you use a lot-

if (dah de dum de dah) {

} - that sort of thing. You can even insert a formal construct and then have parts of your typing mirrored out in it.

You can give yourself multiple cursors with their own buffers so that you can work on multiple lines with similar constructions if you're making pattern type alterations to things.

Any problem that's structured to follow the same sort of pattern, you can probably make the text editor do them for you.

That's more along the lines of why people might want to use emacs. There's a lot of dead-time involved in typing things out that can be automated if you've the tools.

A combination of ido-mode and dired make it incredibly fast to go through the directory structure of any project. It's also really easy to open a shell wherever i am visiting at the moment--including remote directories!--which I've found incredibly useful.

Once I'm in a file, there are a whole ton of movement commands in Emacs that make teleporting around natural. Just one example that seems hard to duplicate in an IDE is the mark: in the course of normal editing, you often set the mark to do things like highlight regions of code. Then, later on, you can cycle back through your old marks, which takes you back through the parts of the file that you were active in. It's like bookmarking a line in the file, except much more lightweight--it happens in the natural flow of working on a file. This is just one example of many very productive features.

Another great example is rgrep. This command lets you search through files in a directory. However, the really cool thing is how it displays the results: you get the filename and the line where the match happened. You can go to the file directly or actually edit it in place in the rgrep results buffer! It's very nice for certain tasks.

Really, Emacs is full of incredibly well thought-out productivity boosters for everything you will do while managing software.

Moreover, it is not limited to language agnostic things. If your want Eclipse-like Java support, you can have it with eclim, which actually uses Eclipse as its backend. I also know of great IDE-like support not based on Eclipse for all sorts of languages from Python through OCaml.

Now, Emacs does have a learning curve. It will take a bit of effort to get good with it. It will probably require changing your entire workflow to take advantage of all the awesomeness. But it's more than worth the time investment: getting comfortable with Emacs is an O(1) action where the benefits it confers are a significant O(n) (if not better!) bonus. The more you program, the more you'll gain.

Learning Emacs gives you significant gains even if most of your job involves browsing around and editing existing code.