As I’ve covered in a previous post, I’m a passionate Vim user; maybe a little obsessive at times (my configs). Setting my love for Vim aside, Emacs, being Vim’s life-long nemesis, presents some interesting benefits. I took a week, this month, to use Emacs exclusively in my work (including C++14, Clojure, and Common Lisp) in order to weigh its benefits. Here’s what I found.

I would never consider trying Emacs if it didn’t have Evil mode. I love Vim’s modal editing and text object navigations too much. However, once I heard from multiple trusted sources that Emacs’ Evil mode is the real deal, Emacs became a more viable option. If I bring Vim to Emacs, I wondered, would there be a net gain? Can Emacs reach parity with Vim and provide a platform for exceeding my current productivity?

My resulting, very cleanly organized, Emacs configs are available here and I’ll be referencing sections of them later.

Compiling

I run a custom/minimal Slackware 14.1 x86_64 built from source. Slackware 14.1 officially ships Emacs 24.3, but I like to run the latest editors and I also like judge build systems, so I built Emacs 24.5.1 from source.

Emacs uses a standard Automake build, so the typical commands will do the trick:

$ mkdir build; cd build
$ ../configure --prefix=/home/jeaye/opt/bin/emacs-24.5
$ make -j8 && make install

Reaching parity with Vim

Once I had emacs installed, I wanted to jump right into getting it up to speed with my Vim muscle memory. Again, I wasn’t looking to re-learn how to edit text, I was seeing if Emacs could provide all I want and use from Vim and more. Let’s take this in sections.

Packaging Related Config

To install packages in Emacs, I highly recommend use-package. You can see, from my configs, just how expressive it is. Combined with lazy loading, it can not only clean up your configs, but also decrease your load times.

Evil mode Related Config

I’ll be honest, Evil mode is superb. The gripes I do have with it are minimal and, in general, it behaves just as I’d expect.

Drawbacks:

• GNU readline chords like ^W don’t work
• J, for merging lines, doesn’t keep a space before/after the merged line
• :e works relative to the current file, not Emacs’ working directory
• There is no :help; one must use Emacs’ help system M-x C-h M-C-S help RET M-h help or something
• Some actions like ^X and ^A, for changing numbers, are left out; I use these a lot
• Evil mode doesn’t have a VimL parser, so only plug-ins which have been ported to Elisp can be used
• ^6, for alternating files, doesn’t work properly; I’m not sure what it’s doing

CtrlP -> Helm Related Config

In Vim, CtrlP is the go-to plug-in for fuzzy finding files and buffers. It’s fast, super easy to use, has sane defaults, and it just works. In Emacs, mimicking CtrlP takes quite a bit more work. The most powerful plug-in which comes into play would be Helm. It supports many extensions which can augment your searches and it provides a foundation for achieving CtrlP-like behavior.

In order to have it work well with Git repositories, Projectile is needed. This will allow Helm to search for files within the current Git repository.

Drawbacks:

• Helm requires quite a bit more setup to get working and its defaults are not nearly as sane
• Since Emacs lacks proper tab support, Helm has no built-in way of opening something in a new tab
• Projectile’s projectile-grep is nowhere near as reliable as vim-fugitive’s :Ggrep, in my experience

Benefits:

• Helm, by default, shows completion options in Emacs’ equivalent of command mode; I haven’t seen anything in Vim which offers real-time mini-buffer completion of fuzzy Vim commands

Airline -> Powerline Related Config

Powerline exists for Vim as well, but it’s very easy to enable with Emacs and it comes with sane defaults.

Benefits:

• Emacs’ platform for rendering is so much more powerful than Vim’s. As a result, there are no font hacks needed to show nice graphics in Emacs

Tabbing Related Config

Vim has built-in tabs in both the GUI and TUI. I don’t use tabs for every file I have open, but I do use them to visually group files in a way that’s more convenient to me than buffers. Furthermore, within each tab, I can have multiple buffer splits laid out as I desire (a tab for a header/source pair, say). Emacs has no official support for tabs and the available plug-ins (escreen and elscreen) hardly do tab-oriented development justice.

I chose elscreen, via evil-tabs, since its reviews marketed it as the newer alternative.

Drawbacks:

• Awful, bloated-looking UI in both the GUI and TUI
• No support for opening from Helm or other buffers
• No support for moving tabs once opened
• New tabs always go to the end, not to the right of the current tab

YCM -> YCM Related Config

Emacs has a slew of auto-completion plug-ins and none of them looked very standard. When I asked around, it seemed nobody agreed on what provided the best completion. Not only are there multiple backends for getting completion data (too many to list), there are multiple front ends for displaying them (Company and Autocomplete, namely).

Fortunately, I found emacs-ycmd which provides real-time completion using Vim’s own YouCompleteMe server. Once this was setup, barring some nasty bugs in the Company front end, completion worked just as I’d like it to. YCM has excellent completion in text files, and its semantic completion in C++ and C# have both made me a happy camper. It’s great that Valloric has made his work available on Emacs.

Drawbacks:

• As you can see in the config, the setup for YCM + Company is terribly verbose
• TAB, in Emacs, means something different to everyone and is not straightforward to just use normally for completions
• Partial completions didn’t work; completing the foo in foo.hpp would put in its own .hpp and leave foo.hpp.hpp; Vim handles this nicely

color_coded

I use color_coded, every day, for C++ work. Unfortunately, there is no alternative in Emacs; no project is even attempting to bring color_coded’s functionality to Emacs. Sadly, it’s a plug-in that I really love and it’s not something I’d want to go without.

Summary

Note, Emacs is an excellent editor. I am not comparing normal Emacs editing to normal Vim editing. I’m evaluating how Emacs is as a Vim-like editor + more.

Am I still using Emacs? No. I stopped after that week, since I don’t see it as providing enough benefits. Vim-like modal editing is the most important aspect, of course, but a Vim-like environment without the thousands of already-written plug-ins is a crippled one. Alas, Evil mode would need a complete VimL interpreter or cross-compiler to assimilate me.

Benefits:

• Elisp is infinitely nicer than VimL

  • I’m a proud lisper and I do a fair amount of Common Lisp and Clojure work. Being able to configure my editor with a dialect of such a powerful language is a huge win.

• Various major modes like Org Mode and the built-in web browsers and IRC clients can make Emacs the proud home of one’s whole programming session

• The possibilities are far less limited than in Vim, allowing arbitrary graphics and a more expressive, powerful programming language

  • Writing a game in Emacs, for example, would be much more approachable than in Vim. How practical this is varies, but it does allow for some complex and useful major modes.

• Emacs’ Lisp support is unparalleled

  • I work in Common Lisp and Clojure frequently, doing both systems-level work and web-oriented work. Vim’s indentation support for Lisps, specifically, is terrible. Emacs makes no mistakes; it’s built in Lisp, around Lisp, and it’s the Lisp editor of choice. This, along with using Elisp for configuration, is what I’ll miss most.

Drawbacks:

• Emacs’ start time is slow

  • Even with use-package lazy-loading my packages, I’m not even fully up to parity with Vim and the start up time is already double that of gVim.

• Evil mode doesn’t cover all major modes

  • Whenever I want to interactively search for packages or do something in Helm, or work in some newly installed major mode, I need to use Emacs’ bindings. They’re uncomfortable and the only reason I explored Emacs with Evil mode was because I thought I could avoid them entirely.

• All of the present modes show up in the status line

  • There is a plug-in, diminish, which helps to resolve this issue. Still, it requires manually specifying the plug-ins to be diminished. It’s a duplication of efforts and an annoyance.

• Emacs employs a GUI-like config editing system which automatically updates your config files

  • This config system may be enjoyable for some, but it’s only frustrating for me. It uses the mouse and normal Emacs bindings; unfortunately, I’ve found that it’s often the only way of really seeing all of the options a package provides, aside from reading the source.

• The discoverability of various plug-ins is lacking

  • In Vim, :help will get you as far as you need to go with any plugin. In Emacs, I found that the myriad of functions, hooks, maps, and modes were nigh unapproachable without copious amounts of copy pasta from others’ configs.

• Emacs’ default coloring is awful

  • Coming from Vim, and hearing so much about the power of Emacs, I really expected more from the default syntax highlighting. For C++, it does a noticeably worse job than Vim out of the box. For other very common file types, there is no highlighting at all.

• Common file type syntaxes don’t exist without third-party plug-ins

  • If you want Markdown highlighting or CMake highlighting in Emacs, for example, you need to install a whole new major mode. In Vim, you have a slew of syntax files out of the box, covering hundreds of common languages. I don’t want a whole CMake major mode, I just want to see some helpful color when I open files.

• Using the solarized color scheme in the terminal is a bad idea

  • Colors in the TUI version of Emacs, in general, seem pretty borked. I’m sure there are some configuration changes I can make, as with anything, or some functions I can write myself, as with most things, which will resolve the issue. However, my point is that it’s not as sane as Vim out of the box.

• Indentation is per major mode and… I just…

  • I’m not really sure what’s going on with Emacs’ indentation. I’ve set the default-tab-width, indent-tabs-mode, c-basic-offset, and c-default-style. Still, for some reason, Emacs likes to indent huge amounts sometimes. As far as non-C++ code goes, it’s even worse. In Vim, it’s neither per file type nor per major mode nor anything else funky.

• Showing full path for buffer names

  • This must be possible. It just must be. Still, as an insane default, and a hard-to-find configuration, Emacs shows short file names as buffer names. In Vim, I can easily see the full file name, relative to Vim’s working directory. This makes it easier for me to create adjacent files or run shell commands. I didn’t find a sane way of doing this in Emacs (uniquify doesn’t do it).

• The state of plug-ins, in general, seems to be behind Vim

  • Bailey Ling makes a point here that, despite VimL being obviously inferior to Elisp, Vimmers are a tenacious bunch. I wholeheartedly agree. To quote him:

    “*There is no dispute that Emacs Lisp is by far the superior language
    when compared to VimScript, but that doesn’t stop VimScript plugin
    developers from making some really amazing plugins and pushing the
    envelope. Vim plugin developers always find a way, no matter how hacky
    the solution might be. It’s fun to be “hacking” instead of “developing”
    after all.*
    
    *To illustrate this point, commandt first came out early 2010, and ctrlp
    came out third quarter of 2011. projectile and fiplr both got recursive
    fuzzy searching the summer of 2013...*”
    

  • He goes on to say that this may also be because Vim is more popular than Emacs. He also describes that, for him, learning Emacs was also about learning a Lisp dialect. I support that with the highest praise, as Lisp has changed the way I think about programming. However, Elisp is, compared to the Lisp dialects out there like Clojure, archaic. It’s not built around generic abstractions, immutability, or even referential transparency. If you want to learn Lisp, please do so; I don’t see it as a sane reason to switch editors though.

Adieu

Perhaps I’ll revisit Emacs later on. For now, my next foray will be into the land of Neovim where color_coded has already been experimentally ported to the new async API.