Is it worth investing time in learning to use Emacs?

StackOverflow https://stackoverflow.com/questions/48006

  •  09-06-2019
  •  | 
  •  

Question

Right up front: I do not want to start a religious war.

I've used vi for as long as I can remember, and the few times I've tried to pick up Emacs I've been so lost that I've quickly given up. Lots of people find Emacs very powerful, however. Its programmability is somewhat legendary. I'm primarily doing Solaris+Java development, and I'd like to ask a simple question: will my productivity increase if I invest time in getting my head around Emacs? Is the functionality that it offers over Vim going to be paid back in productivity increases in a reasonable timeframe?

Repeat: I don't want a "my editor is better than yours" answer. I just want a yes or no answer as to whether it's worth investing the time or not. Will my productivity really increase?

Was it helpful?

Solution

I prefer emacs to vi, but I'm comfortable in both.

There are some things that you can do in emacs that make it more powerful than vi, but not all of them are even programming-related. (Can you send email or read news from within vi? No, but who cares?) If you're comfortable with lisp (I'm not), you might be able to write add-ons and modes and stuff to make your life easier, but that's just likely to be syntax colouring and brace matching and eye candy like that.

I will stop rambling now. Will your productivity increase using emacs? No.

Update: See my comment below. Since I posted this, I have come across ways that using emacs has made me more productive than using vi.

OTHER TIPS

[Disclaimer: personally, I prefer Vim. Disclaimer disclaimer: read on.]

Vim excels in the small: by making motion and action separate concepts and providing facilities for complex repeats, you can perform incredibly powerful editing operations in just a short sequence of keystrokes. You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs. Also, most of the power you use comes out of the box, so even if you have extensive .vimrc customisations, chances are you will be able to work productively with any Vim installation.

Emacs excels in the large: by mapping all of its UI concepts directly to basic constructs and concepts in Elisp, it becomes very easy to globally introduce features for specific kinds of files or circumstances, making Emacs something like a text-based and much more structuredly programmable form of Excel. This presumes that you are going to spend a lot of time customising your environment for personal needs and preferences. Of course, Emacs does do its best to make it easy to stay inside that one environment for everything and anything you may want to do.

Ultimately, neither is superior. They offer different styles, and depending on your proclivities, one or the other will suit your personal needs and way of thinking better. It is always helpful to know both (plus more editors), of course. But you aren’t going to be appreciably more productive this way or that.

vi is a kitchen knife.

vim is a really nice, sharp, balanced chef's knife.

Emacs is a light saber.

Most of the time, my job requires me to chop vegetables. Occasionally, I have to take on an entire army of robots.

I've been using Emacs for 20 years. I'm typing in Emacs right now with a widget called "It's All Text" that lets me suck text in and out of text boxes in Firefox. I can go really fast in Emacs. I am significantly less productive without it.

This is highly debateable, but I also think that learning Emacs can teach you a surprising amount about programming.

Depending on how you code, you may see a productivity increase. For background, I'm also a long-time vim user, but I learned emacs about 2 years ago, and now use them interchangeably.

What drove me to the point of actually learning emacs was its useful ability to have a large number of files open at once, and to easily switch between them. I was in the middle of introducing a feature that added and touched a large number of classes. (This was C++, so there were typically two files per class.) Since I was still firming up the interface, I would typically be in the middle of updating one file when I would realize that I needed to change another.

With gvim, it was easiest to open a new window for each file, which was starting to get unwieldy. With Emacs, though, it was simple to open a new file in the same window (Ctrl-x, Ctrl-f). Once Emacs has a file open, it's very easy to switch back and forth between the open buffers (Ctrl-x, Ctrl-b).

Taking that one step further, a single emacs session may open many windows, so in addition to splitting the window vertically, I could decide, without interrupting work on a file, to open another next to it, letting me effectively work side-by-side while still keeping each window at the default 80-character width.

There are still some things that I find easier in vim (e.g. block-select mode, simple macro recording, diff mode), and things that are easier in Emacs (line alignment, file/buffer management, window/screen management). Therefore, I find myself alternating between the two (and sometimes using both simultaneously), depending the editing task I anticipate.

If you're still unsure, I'd suggest trying it out. Run through the Emacs tutorial and then use it to write code for a morning or a day, leaning heavily on the help. If you still don't like what you see, stay with vim. Regardless of what the editor brings to the table, your familiarity and knowledge of the tool will by far be the most important factor in your productivity.

I don't want a holy war, but please answer a highly subjective question with a yes/no answer.

Yes, you may see a productivity increase because of the powerful functionality.

No, you will not see a productivity increase because the patterns and metaphors used in emacs may not align with you brain.

The short answer to your question is, "YES". More detail below.

I used vi almost exclusively from about 1980 to 1991. The only time I didn't use vi was when I was dealing with a minimal install of Unix that was too small to include vi, so I had to drop back to ed which is the minimal subset of editing functionality that the original vi was built on top of.

From about 1985 on, other programmers where I worked were constantly singing the praises of emacs. But every time I'd try to learn it I wouldn't get very far. I'd spend an hour going through the emacs turorial (C-h t) and by the end of it all I'd know would be how to insert and modify text and move around the screen. I could do so much more with vi than what I'd learned in that hour with emacs that I couldn't make the switch. Three months later I'd find time to spend another hour and I'd end up going through the same material. Emacs has a Learning Curve with a capital "L". It wasn't until I was doing a contract where everybody else used emacs that I eventually decided I needed to devote more than an hour at a time to learning it. After spending a little over a day doing nothing but working through the tutorial and the included documentation, I finally got to the point where I could do things with emacs that I couldn't with vi. From then on, I've never wanted to go back. I can still type vi commands in my sleep, but I can do so much more with emacs.

Understand that I'm comparing emacs and vi, not vim. I've never learned the extensions that vim has added to vi, and it's likely that many of them are features copied from emacs. If so, and if you're already proficient with vim, emacs may not hold as many advantages for you.

Among the things I depend on all the time in emacs are:

  1. When you use emacs, everything's treated as text. This means that you can manipulate any data in any buffer with pretty much the same commands. And in cases where a buffer's in a mode where some of the standard commands are unavailable, you can copy text to another buffer running in fundamental mode and use the standard commands there.

  2. Emacs provides a multi-"window" environment displayable in on a character-cell terminal. In the days before bitmapped graphics and real windows, emacs was written to simulate window-like behavior using nothing but ascii characters and cursor positioning. You're probably thinking, "That's ancient history. Why should anyone care about that today?" I still use that capability every day. I use a webhosting company that allows me SSH access. So I can log into a Linux host across the Internet and run shell commands. While that's pretty powerful, it's far more powerful to be able to divide my terminal emulator up into "windows" using emacs, run shells in several of those "windows", edit files in other windows, and view and edit directories in still other "windows".

    Actually, when I said "window" in the previous paragraph, I really meant "buffer". Emacs' character cell emulation of windows is a way of dividing up the screen real-estate. An emacs buffer is associated with content (a file, a bash shell, a directory, arbitrary text not associated with a file, etc.) which may or may not currently be displayed. To view what's in a buffer, you pick a window and tell it what buffer you want to see. So you can be working on way more things than you have space on the screen to display. It's roughly analogous to what you do in a modern bitmapped-graphics GUI when you iconify/de-iconify a window.

  3. I've already alluded to the fact that you can run a shell inside an emacs buffer. You can have as many buffers running shells as you like. You can copy and paste text back and forth between a shell buffer and a text file, or compare a portion of text between a shell buffer and a text file using the exact same keystroke sequences you would use to copy text or compare text between two different text files. Actually, this is true for most types of buffers, not just shell buffers and buffers associated with files.

  4. When you use emacs' command to open a file, but what you've selected is actually a directory, the buffer runs in dired (directory editor) mode. In this mode, a single keystroke will open whatever the cursor's currently pointing at, be it a file or subdirectory. A buffer in dired mode is a file manager - a character-cell terminal oriented analog to Finder on the Mac or Windows Explorer.

  5. One of the emacs functions I use almost constantly is "compare-windows". I greatly prefer this to command-line "diff" or GUI comparison tools like what's built in to Eclipse. Diff or Eclipse compare entire files, and show you which lines differ. But what happens when you have two different lines that look very similar? Consider the following:

    What's the difference between this line and the other?

    What’s the difference between this line and the other?

    How long would it take you spot the difference? (Hint: ASCII and Unicode apostrophe look pretty much alike.)

    Unlike diff and Eclipse, which just show the lines that differ, emacs' "compare-windows" function is interactive. You position the cursor in each of two side-by-side windows at a point where the window contents are the same. Run "compare-windows", and the cursor in each window will move to the first character that differs. Reposition the cursor in one of the windows to the point where it's the same as the other window, and rerun "compare-windows" to find the next difference. This makes it easy to compare subportions of files.

    Another thing I regularly use "compare-windows" for is comparing checksums. Many software projects distribute a tarball of the application on a page that also includes an MD5 hash of the tarball. So, how do you compare the MD5 hash on the distribution page with the MD5 hash computed from the downloaded file. Emacs makes this trivial.

    First copy the MD5 hash from the webpage into a new emacs buffer. Then, after downloading the .tar.gz file, run:

    md5sum downloadedfile.tar.gz

    in a shell buffer. With those two buffers displayed in side-by-side emacs windows, position the cursor in each window at the beginning of the checksum and run "compare-windows". If they're the same, the cursor in each window will be positioned at the end of each checksum.

  6. In the previous point, I gave the example of running "compare-windows" on the lines:

    What's the difference between this line and the other?

    What’s the difference between this line and the other?

    "compare-windows" will leave the cursor positioned on the apostrophe in each line. So, now you know which characters differ. But what characters are they? Type the two keystroke command CTRL-x =, and emacs will display the character, its ascii value in octal, decimal, and hex, the character offset from the beginning of the file, and the character offset from the beginning of the line. Since ASCII is a 7-bit encoding, all ASCII characters have their high-order bit turned off. Once you see that the value of the first apostrophe is 0x27 and the second one is 0x92, it's obvious that the first one is in the ASCII character set and the second one is not.

  7. Emacs was one of the first IDEs, perhaps the very first one. It has modes for specific languages. I find them handy for imposing consistent indentation on my code to make it more readable. There's also built-in functionality for compiling and debugging code. I don't use the compiling functionality that much because when I was writing for a compiled language like C, I was used to doing that at a shell prompt. The debugging functionality was very nice for C and C++. It integrated gdb with the editor in such a way that you got pretty much the same functionality as the debugging capabilities now in Eclipse, but didn't waste screen real-estate the way modern GUI-based IDEs do. Theoretically the debugger integration should be easy to make it apply to virtually any other language, but I haven't checked to see what other languages it works with nowadays.

  8. Emacs allows you to create macros by telling it when to start remembering what you're typing and when to stop. This is extremely powerful for tasks you frequently do.

  9. Emacs is infinitely extensible if you know Lisp. But even though I've never learned Emacs Lisp, I still find Emacs one of the most powerful tools I've ever used.

  10. Emacs key-bindings. I'll be the first one to admit that Emacs key-bindings suck. But it's so much more powerful than anything else I've used, that I'm willing to put up with the key-bindings.

  11. In a humorous vein, years ago Emacs' author Richard Stallman (also originator of the GPL, founder of the GNU project and founder of FSF) lampooned those who treat vi vs. emacs as a holy war. He invented the character "Saint IGNUcius" of the Church of Emacs. In that guise, Stallman commented, "Sometimes people ask me whether it is a sin in the Church of Emacs to use the other text editor vi. Well, it's true that vi vi vi is the editor of the beast, but using a free version of vi is not a sin, it's a penance." (See http://stallman.org/saint.html. There's also a cute photo of him, but since I'm new to StackOverflow, it won't let me post more than one URL. So go to the same domain, but fetch the file saintignucius.jpg)

I used Vim for 10 years leading up to delving into Emacs 2 years ago. I have a reasonably fresh recollection of just how my productivity curve modified over time.

My points are all conditional, YMMV depending on your strengths and experience.

If you have used Unix and the command line long enough that you are familiar with C-a, C-e, C-n, C-p, C-k, C-y, etc as they function on the shell, it will not take long to transition to using those same bindings (the defaults) in Emacs. I recently discovered that XCode uses these bindings as well.

If you are comfortable with an always running editor, tending buffers (like you would browser tabs) and thus living in the application (like you would with Web2.0 apps in the browser), Emacs will likely show immediate productivity enhancements.

If you generally work in projects of many related files, this persistence pays some added benefits in maintaining context to that buffer. Each buffer is contexted at its open file allowing for convenient use of various productivity boosting tools for your that project (like grep-find, eshell, run-python and slime). This coupled with text completion, yasnippets, etc start to look a tiny fraction like an IDE although ad-hoc and heavily individualized by your configuration. This is apart from more civilized Emacs IDE-like services like ECB.

My productivity took a hit initially as I typed "jjjkkk" constantly Esc-Esc-Esc-Esc for the first week or so. The following week I cautiously started using the right navigation keys. Then I discovered the configuration file... Honestly, if I had had Emacs Starter Kit from the start, I would have said my productivity slowly worked back to parity over the 3rd-4th week but I did go down the config file rabbit hole. A co-worker of mine, though, has just transitioned from vim to emacs and he just grabbed the Starter Kit and he is on his way. First week in and he seems comfortable and enjoying all the surprise benefits (that sensation will probably last a decade).

Finally, if you make mistakes you will immediately gain productivity (and confidence) from the circular kill/yank-ring and undo-ring. I am also personally a fan of region specific undos.

My short answer is Yes it is worth taking 3-4 weeks of a diminishing productivity-hit to learn Emacs. Even if you decide you prefer a streamlined unix utility combo over Emacs for development you will derive from it an education widely applicable beyond the editor.

Emacs documentation is a forest. I came from Emacs to Vim when I realized how organized Vim's documentation is, and how chordable many of the features are. I don't know what lies down the path of an Emacs expert, but I will warn you that learning to do anything useful in it takes a long time, and won't make you any better at nethack. Stick with Vim.

Textmate is a better Emacs for Macs, though that won't help you with Solaris. Eclipse is kind of cool, and has a lot of plugins.

Emacs will provide a productivity gain if you're willing to learn and customize it to fit your needs. Most people are not. To increase your productivity you must use the tool for more than simple editing - most people never progress past simple editing.

Here's a quick test: have you customized your window manager to make your environment more efficient (tailored to fit your needs)? If 'no' then likely you will not get the ROI by learning emacs.

That being said, if you're developing Java, Eclipse is the standard answer, so your question is pretty moot.

I was very happy with my Vim, but once I heard of org-mode, I started learning Emacs. org-mode could be one strong reason to learn Emacs.

I love emacs and use it every day.

That said, I don't think the cost of learning it will be recouped by productivity gains down the road.

If you're programming Java, you need a good IDE. Emacs goes a fair way towards being one, but let's face it, IDEA et al beat it hands down. (emacs probably inspired a lot of those IDEs, but that's another story).

Twice I've tried to learn Emacs. It just doesn't fit how my brain works, and so I don't use it.

Emacs (or vim) is not significantly better than vim (or Emacs). Both have many options to add to them that allow them to do amazing things. I have no doubt that anything you can get done in Emacs you can also get done in Vim, just not standard.

Try Emacs. See if it fits better. It's a no-lose situation.

I want to look into emacs further, but I just can't use it for long stretches of time; it hurts my hands. Am I doing something horribly wrong?

vim and emacs, they are THE most capable editors and have been for quite some time. If you know one really well, I doubt that you will gain that much in the process...

However, it is always a good idea to look into what plugin that are available since a couple of new plugins can do wonders for the productivity.

/Johan

No (and I've used both).

Along the same line of not looking for a religious war (but go ahead and downvote me if you feel you must), why do you feel that the only option to vi is emacs? Is it the OS you develop on, or just the options you explored?

The Java development landscape enjoys some of the best IDEs these days (both free and paid for), if not the best when it comes to code editing and refactoring support.IntelliJ IDEA even has a vi plugin that can help you feel more at home, for instance (not sure if something similar is available for Eclipse). While changing tools does imply a learning curve, the time spent doing it might be worth it if the leap is big enough.

How fast do you type? If you hunt and peck, then emacs is not for you. If your fast tho, it can help not having to grab your mouse all the time.

Generally, emacs is more powerful than vi. You could do a lot more things in emacs.

You're productivity will increase if you decide to put the time in to program your text editor. Of the two editors, emacs presents a better framework or constant customization. If you don't program your text editor, just stay with what is comfortable.

One good reason to learn Emacs is because other programs use Emacs keybindings too. You can use Emacs keybindings at a bash prompt, for example, or anything else using GNU readline. It's good to learn the basic movement and word/line deletion and undo/redo chords in Emacs so that you can use them in other programs. Your productivity will increase in those other tools even if you never use Emacs again.

I know Vim and Emacs, and Vim fits my brain and my habits better. But other people claim the same about Emacs. You never know for yourself unless you try. It doesn't take that long to learn Emacs well enough to see whether you're going to like it.

Will my productivity really increase?

For the first few days/weeks, absolutely not.

After you stop having to read through the tutorial every time you want to edit something - sure..

Emacs is more "powerful" than vim, it's scripting engine is far more flexible, and there are far more scripts, modes and the likes built around emacs.

That said, the opposite is true.. If you spent the same amount of time improving your knowledge of vim, you'd could be just as productive..

Maybe not productive in the same way - I'd say vim is quicker for editing files, emacs is better at doing everything else (again, I would personally say things like flymake-mode, VCS bindings are such are quicker to use than the vim equivalent)

I agree with Alan Storm: "because the patterns and metaphors used in Emacs may not align with you brain"

This is a very important factor. Different brains adapt differently to different interfaces.

Some of the main - and easily available - features I really love Emacs for, and I count as productivity enhancers:
1. "yank-pop" facility - every cut/copy is saved into a stack so you can later choose which to paste (don't know if vi / Vim has this but most Java IDEs don't)
2. the Ctrl-key navigation mapping - this allows you to navigate your file without moving your hands off to use the arrow keys. (key-binding in other editors helps of course)
3. available on almost every platform (true of vi/Vim too of course) - whether GUI- or text-based (Java IDEs are available on most platforms too but only in GUI mode, and are significantly larger and need to be installed separately whereas Emacs is generally more widely available - BSD / *nix / Linux / Mac systems
4. I prefer my editor to stay out of the way until I need it - Emacs' spartan display forces me to think before I type.
5. The basic navigation keys in Emacs are kind of universally available - on my Mac OS, I can use these keys in terminal, mac mail, etc.

Ultimately, if Emacs' philosophy appeals to you, you will put in the extra effort to learn it. And it will reward you.

Since vi/Vim and Emacs are pretty close in terms of what they can or cannot do, productivity with these two editors comes from experience in using it.

In my opinion, being a programmer it won't take you long to get the general idea about Emacs once you start using it. Others can only say so much, you got to try it out for yourself to know it.

As for me, I use both. It's like taking more than one weapon to a war, use the right one in the right circumstances. ;)

I like Emacs, you can extend it by your needs- in my eyes, any system which you can extend by yourself is award-worthy.

Disclaimer: I'm ignorant. I've been an emacs user for about 4 years, and vim user for about 6 months, maybe more like 15 if you count all the times I've tried to learn it and hated it. (The writing vs moving mode distinction kills me. Every time. So if it doesn't kill you then my opinion might be completely worthless.) That said, I think my opinion is actually interestingly different from the 26 others that I've seen on here, so I'm going to voice it. :Disclamer

My opinion:

  • Emacs is better for typing, especially large-scale "I'm writing a new feature and it will be a while before I even try to see if it runs".
  • Vim is better for editing, especially quick edits.

When I need to understand and hack in 8 files simultaneously, Emacs' properties as a tiling window manager with multi-buffer (buffers have a 1.2:1 correspondence to files, they're often the same thing, but aren't necessarily) regexp-search (and replace) are incredible.

If I don't like some small thing because of git diff in the shell (I don't use emacs' VC features very often, although when I do I love them) I open it with vim and get the hell out faster than I could hit Alt-TAB.

The fact that Emacs' editing commands are more readily available while typing make typing much faster than it is in Vim. Ctrl+a is much faster than ESC ^ i, and you don't have the cognitive load of "do I want a or i or o or O..." which, god, I hate thinking about. And same for all the other movement commands commands.

I type faster, much faster, in Emacs. That means things like Org Mode (which I use for everything: TODO lists, bug tracking, notes, long emails, documentation...) make more sense (to me) in Emacs than they would in Vim.

And, Elisp is incredible, even though it sucks. It totally makes up for Emacs' broken regular expressions: you can use the full power of emacs everywhere, including in a multi-file regexp-replacement. And in text snippets.

If you are concerned about the health of your hands choose Vim.

I suffered from a bout of RSI in the past, and I found one of the main culprits was "chording" i.e. holding down many keys at the same time. Emacs uses chording extensively whilst VIM uses single letter commands chained in quick succession. This puts much less strain on your hands as the muscles don't have to twist and contort to perform commands in the editor. Injury due to RSI can ruin your productivity so in your calculations be sure to account for this.

I really see no reason to switch. I've used vi for a long time and am quite comfortable with it; about every six months I would install emacs to give it a go, then quickly just switch back. Yes there were things I much preferred about vi, but the main reason I never stuck with it is because the time investment to fully learn another editor when I already know an extremely capable one isn't worth it.
I'm reminded of this rather dated study.

In my opinion, SLIME is about the only reason to switch to emacs if you're already proficient with vi.

No

I've been using emacs for years, I'm a convert from VIM, and I love it to bits.

But any productivity gains from having a better, programmable editor will be totally wiped out by the enormous amount of head-fucking that it takes to get the hang of emacs. It was designed as a console editor, and its idea of interface is not yours.

And even when you've got it completely, your extra productivity will mainly be expressed in the extra emacs lisp you can write.

Who cares? It's great fun, and lisp is the dogs! If you want to 'get things done', then forget about programming. You can always hire programmers to 'do' 'things'.

The only circumstance under which I'd recommend learning emacs for productivity reasons is if you're a lisp/scheme/clojure programmer. It makes such a good lisp environment that then the few seconds it will save you every time you want to do anything will quickly add up to a real gain. And elisp (which stands in relation to lisp as excel macros stand to ALGOL) will seem much less alien if you already use a real lisp.

If you do give it a try, use it on a virtual console where it feels more like a sane way to arrange an editor. Only when that makes sense try to use it under a window system, which will fight with it.

In an earlier answer, Aristotle Pagaltzis wrote: "Vim excels in the small ... You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs."

I switched to Emacs after over a decade of exclusively using vi, and initially I would have agreed with the claim, "You can easily do things in Vim in the normal course of editing that would require you to drop down to scripting in Emacs." But then I discovered that by using Emacs' macro capability and a large repeat count, I could easily make Emacs do pretty much everything that vi had made easy, and a great deal more.

Emacs' macro functionality involves three commands:

C-x (       start remembering keystrokes
C-x )       stop remembering keystrokes
C-x e       replay the remembered keystrokes

For example, in vi if I wanted to find all <a> tags in an HTML file and add a target attribute, I might do something like the following:

:g/^<a/s/>/ target="_blank">/

This example is not perfect, since it assumes that all <a> tags are on a line by themselves. But it's good enough for illustrating how one accomplishes the equivalent task in two different editors.

To achieve the same effect easily in emacs, here's what I do:

1.  C-x (
2.  M-C-s <a\>
3.  C-b
4.  C-s >
5.  C-b
6.   target="_blank"
7.  C-x )
8.  C-u 10000 C-x e

Here's a description of what each keystroke above does:

1.  start remembering keystrokes
2.  regex search for <a.  Note that the "\>" after the "a" is not HTML.  It's emacs regex notation for end-of-word.
3.  back up one character - as a side-effect this gets you out of search mode
4.  search for the next ">"
5.  back up over the ">"
6.  enter space as an attribute-delimiter followed by the target="_blank" attribute
7.  stop remembering keystrokes
8.  replay the remembered keystrokes 10,000 times or until the search fails

It looks complicated, but it's actually very easy to type. And you can use this approach to do lots of things that vi can't do, without ever dropping down to Lisp code.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top