My pragmatic decision on GNU Emacs versus vim for my programming

August 21, 2016

One of the reasons I've been thinking about vim lately and working on learning it more is that I've been flirting with the idea of switching to using vim for all of my programming in order to focus all of my attention on one editor instead of splitting it across vim and GNU Emacs as I nominally claim to do. The reality is that I already spend most of my editing time in vim, because these days I don't do much programming (especially in the languages I use GNU Emacs for). Given an increasing use of vim and thus increasing fluency in it, and low GNU Emacs use (with a slow loss of fluency), I thought it might make sense to just go all in on vim. Vim has all of the basic features that I need to be productive (like windows on multiple buffers aka files), and it also has its own well developed form of super-intelligence (and plenty of people who like it a lot).

I'll put the conclusion up front: I'm not going to do that. I've decided it makes more sense to stick with GNU Emacs as my super-intelligent editing environment (and maybe get a bit better at it every so often).

What ultimately changed my mind today was the experience of experimenting with GNU Emacs' flycheck (and go-flymake's addon for it). Specifically, that the whole exercise took me only a couple of minutes to get going and everything basically just worked. I'm sure that there's an equivalent plugin setup for vim and an experienced vim person could get it up and running in no time flat, but I'm not that person. For better or worse, GNU Emacs has worked out a whole complex ecology of ELPA and MELPA and then buried all of the complexity so that it pretty much just works for people like me. I'm a lazy and pragmatic person these days (eg), and for all my agonizing and contemplating, I still know enough GNU Emacs to be productive and GNU Emacs makes it easy for me to just get code written in a sophisticated environment with a lot of niceties that generally just work.

(I don't know enough about the world of vim plugins to know if super-intelligent stuff is more likely to appear for GNU Emacs than for vim, and of course my current impressions are biased by the fact that MELPA seems to have this massive list of everything)

This isn't to say that getting code written is hard in vim. With work I could probably assemble a vim environment full of equivalents of magit and company-mode and so on, I like vi's overall approach, and I'm going to reach the point where I'm better at editing in vim than in GNU Emacs. But since both GNU Emacs and vim are quite capable editors and I already have a good GNU Emacs environment that I find easy enough to do things in, it seems unlikely that switching exclusively to vim would make a huge difference, especially given that I don't write code in GNU Emacs all that often (cf Amdahl's Law). Instead it seems more likely that I'd spend a lot of time churning around and wind up more or less in the same spot, except using vim commands instead of GNU Emacs ones. That's not enough of a win to be tempting, not any more.

(To head off the obvious suggestion, for various reasons I'm not interested in trying to use vi keystrokes in GNU Emacs. If I'm going to be using GNU Emacs, I have a lot of experience and reflexes built around its native key bindings.)

There's a part of me that regrets this (the same part that likes the idea of Rust). It would quite like to embark on the grand (and periodically frustrating) adventure of (re)building a sophisticated editing environment in vim, learning all about vim plugins, and so on, and even now it's busy trying to convince me that I'm making a mistake and I'm only going to frustrate myself by continuing to go back and forth between vim and GNU Emacs instead of mastering vim (and finding cool plugins for it). The rest of me has other things to do.

(And I admit that I still like GNU Emacs, and not just because you can put the kitchen sink into it. I've edited a lot of code (and text) in GNU Emacs over the years and in the process I've gotten quite used to it. I didn't drift away from it because I dislike it, I drifted away because it doesn't make for a good sysadmin's editor.)

Comments on this page:

My general impression is that the average Vim plugin is less super-intelligent than the average Emacs plugin. Maybe a lot less. I don’t think Vim actually has a significant ceiling, but it makes you go a lot farther just to get to the same place. Like you’ve said before, Emacs is built out of primitives exposed to elisp, whereas Vim’s scripting is attached to the side of a monolithic editor.

One problem is that not everything about the operation of that monolith is exposed. But almost worse is that many accessible parts are exposed through special forms of various kinds, rather any kind of uniform interface, and they can be… idiosyncratic. E.g. there is no function to set name of a buffer, but there is the :file command, which creates another buffer in the process, and also sets an annoying flag on the re-/named buffer which is not exposed directly. So conceptually simple actions may require a lot of code (or very carefully arranged code) to work around the presumptions of the monolith.

It is obviously plausible that this might discourage people from swimming upstream.

Emacs doesn’t put obstacles in your way like that, so it does not in any way contain the ambitions of plugin authors.

By @nxadm at 2016-08-21 05:56:26:


Not trying to convince to change your opinion, just a heads up the notes I posted today on configuring Vim as a Perl 6 editor. The same steps can be use for other languages you use (from your posts I support Go and Python for you):

For the last step autocomplete you need to build the plugin with semantic support for Python and Go so you can get semantic autocomplete instead of fuzzy autocomplete.

@nxadm at twitter if you have a question.

By Marin at 2016-08-21 16:42:20:

Why not try evil mode? It's an amazing Vim emulator for Emacs. This way, you get the best of both worlds ;)

By Filip Miletic at 2016-08-25 14:43:58:

I am in similar situation to yours, where I can't make up my mind about which editor to stick with. But keep in mind that I am student and not sys. admin. so my hands aren't tied to some specific scenarios.

But what amazes me the most about Emacs are plugins. I mean, when you compare them to vim plugins, I feel they aren't the same scale. Emacs plugins for specific languages are full blown environments, maybe best in their field. Plus I am learning Lisp, and Emacs is inevitable in that case. And with sticking with Emacs I feel like I am making better long term decision. And that could be the deciding factor, that I know deep in the guts that I will not regret my decision in a few years. What is holding me back is that I used Vim for 3 years, and established flow in my iterm2+zsh+neovim environment. I got to the point where I do not tweak it much and just use it. And I found the philosophy of modal editing very appealing, I think even more after I tried emacs and all those C- M- keybindings.

I know just one thing. I do not want to keep myself thorn like this, it tiers me, I feel like wasting time thinking about both editors, using both too, instead I could spend time smarter and learn one much better. I mean, decision will fall, sooner or later, but I do not know why it is so hard. I am really picky about my tools and configs, people tell me I am config freak, but I like to spend my free time tweaking and playing with system and my work environment.

By kirk at 2017-02-07 14:28:37:

vim is a cost / benefit application. benefit is when you can switch from workstation to headless server and use the same editor. cost when you have to sort out all the various plugins you will need to get things done. costs are plenty no doubt. ultimately these tools are only as good as the community that supports them. it would be interesting to survey folks about their vim / emac tendencies, what languages they are using and how old they are.

Have you tried Spacemacs?. Its slogan says: "A community-driven Emacs distribution. The best editor is neither Emacs nor Vim, it's Emacs and Vim!"

Written on 21 August 2016.
« My current Go autocompletion setup in GNU Emacs
An interesting case of NFS traffic (probably) holding a ZFS snapshot busy »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Aug 21 00:38:56 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.