So long, Vim. I’m returning to Emacs

I’d been using Emacs for quite awhile, and about 8 months ago I decided I would try using Vim. I’d only used vi for system emergency work, but knew a number of people that swore by it for regular work. So I decided I would learn Vim and use it for my regular work. I figure that with things like this, I don’t get a real feel for how well they work unless I use them for all my work. So I haven’t really opened Emacs at all in the past 8 months.

Yesterday I finally decided that Vim was not living up to my expectations and I’m in the process of switching back to Emacs. I thought I ought to write down why I’m doing that, for my own future reference… and since nobody has ever written about Emacs vs. Vim, I might as well post it where everyone can see it.

So here we are.

Original Reasons for Using Vim

It would lead to more comfortable typing. Lots of Vim users mention that you don’t have to hold down keys while hitting other keys as much in Vim as in Emacs, and that the movement keys are all on the home row. That’s true, but I didn’t find it to be that big of an improvement, since Esc is a farther reach than anything in Emacs, and let me tell you, you’re hitting Esc all the time in Vim. I found that removing the armrests from my chair made my hands happier than Vim ever did, and swapping Ctrl and CapsLock in Emacs will probably help there too.

It starts faster. I’m not sure if that really was true even when I switched, but it certainly isn’t true on any of my machines today. Both Vim and Emacs have had major version upgrades (v7 and v22, respectively) since I started using Vim. People seem to say that Emacs 22 feels faster, though I don’t know if that’s true. The startup times of the two, if they’re different, are imperceptible.

Vim would use less RAM. Frankly, these days, both Emacs and Vim are way down on the list of things that use up RAM. Heck, kmail has 141MB resident, and each of its two IMAP processes is using more than 30MB. Emacs in X right after start has 16MB resident, 10MB of which is shared, and 25MB VSS. gvim right after start has 8MB resident, 5MB of which is shared, and a 43MB VSS. Emacs tends to use fewer processes for things that vim. So they’re not all that different, and Emacs could come out smaller in certain situations. But the difference is irrelevant on today’s machines, and modern Gnome and KDE apps are many times larger than both of them.

It will make me more comfortable in rescue environments where I have only traditional vi available. Actually, the vi on AIX is so different from modern Vim that this didn’t really help.

It would make me more productive. There are some editing commands that did, but as you’ll see below, it was more than balanced out by other problems.

Things I Liked about Vim

The commands dt, dT, df, dF. Wonderful little things those. Emacs now has M-z (Zap), which is similar to df but can actually go to other lines (a nice addition). And there are easy ways to bind keys to the others as well, though that doesn’t make it a pervasive convention like it is in Vim.

Antialiased fonts. It’s crazy that Emacs doesn’t have this yet. But not a showstopper; I still like good ole 10×20 just fine.

Regexp search-and-replace. Emacs actually has this now, and maybe it had it back then too. M-C-%. Apparently in Emacs22 the replacement expression can also have lisp code in it, which sounds really slick but I can’t see myself using it regularly.

Annoying Things in Vim

Syntax highlighting. The syntax highlighting for most languages in Vim felt like it was about as smart as it was in Emacs about 10 years ago. Strings like "Hello!\"" (in languages where \” inserts a literal “) often confused it. Sometimes quotes within comments confused it. Sometimes it would be confused permanently. Other times, just until I scrolled around in the file or reloaded it.

Indentation. This is much more annoying than the syntax highlighting, really. In many languages — and especially the two modes I’ve used most recently, XML and Haskell — it really, really stinks. The indentation there isn’t aware of syntax, or not very much. Sometimes it is smart enough to know that if an XML line starts with

I’ve asked Vim experts about this, and have tried all sorts of various tweaks, have read through Vim indentation mode source files, etc. There is just no way to get it anywhere near the intelligence of Emacs for most languages, short of writing my own mode, it appears. This is even worse because when using the backspace key in insert mode, for awhile it deletes individual spaces, and then all of a sudden deletes a big chunk of whitespace back to the beginning of the line. (And no, the insertion of Tab characters is disabled.) Indentation is my #1 complaint about Vim, and something that shows no progress towards being fixed any time soon.

And forget about anything like Emacs M-x reindent-region. This is a syntax-aware indenter. You can write out an entire source file with no indentation whatsoever, and it will indent the entire thing according to the indentation rules you’ve defined and the syntax of the language you’re using. The best I’ve seen in Vim are commands that add or remove space at the beginning of every line in a region.

In short, Emacs seems to “understand” the file format on a much deeper level than Vim, and can automate things to a much better extent because of it.

Too many things disrupt the paste buffer. I can use Y or y to yank some text in Vim, and it’s really, really easy to overwrite that buffer with other things. Yes, I know that I can yank it into a named buffer, but that’s inconvenient and I don’t usually know in advance that I’ll have that need. In Emacs, only C-k and other “large area” commands disrupt it.

Vim doesn’t like you having lots of files open at once. It’s surprisingly convoluted to do this. If you use the basic documented command to edit another file, :e, it closes the file you’re working on. The normal way to open multiple files at once is to use split windows. Well, I don’t like split windows all that well, and often just want to make a quick change in one file — in full screen — and then go back to another. Even though I use set hidden in my ~/.vimrc, it still is annoying and more convoluted than it should be.

Vim can’t create new top-level X windows. In Emacs, I can press C-x 5 2, and poof, I have a second Emacs window in X, and it’s tied to the same editing session and Emacs process. Not a new process, with a different set of files, its own buffers, etc. The same process, same set of files. Just like a split window, but with a new top-level X window instead. gvim simply has no way to do that. This is also a large annoyance.

gqap stinks. This has burned me more than once. I’ll be editing an XML document, and insert some text in the middle of a paragraph. Now I have a really wide line. So I type gqap to reformat the paragraph. My cursor is near the bottom of the screen, so I don’t really see much past the current line. I then save the document and exit. Later I discover that vim considered the entire rest of the document part of the single paragraph, and removed all the different indentation levels at and the like, so it’s completely messed up. Emacs is smart enough to know what is a paragraph in XML mode, and M-q does the right thing. Oh, and Emacs reindent-region can fix the Vim gqap-induced mess.

109 thoughts on “So long, Vim. I’m returning to Emacs

  1. Okay, I’ve started using tabs now. I don’t know why I wasn’t before. Now the lack of multiple top-level windows doesn’t bother me any more.

    Thanks to all the people who reminded me of that!

  2. I see that you noted comfortable typing as a pro in Vim’s column. That is basically what is forcing me to move over to Emacs. I haven’t even tried Vim, but I know if Vim doesn’t work out then I’ll just have to use an IDE.

    The issue with comfortable typing isn’t so much keeping your fingers on the home row, it is reducing possibility for injury. The usage of control (or even caps lock) with your pinky is just too uncomfortable for me.

    So even taking into account all the crazy stuff Emacs can do (I love and will miss dired), I just don’t want to permanently injure my wrists.

  3. On my first Unix course several years ago I was told it will take up to two years to learn vi properly and effectively. Strange stuff I thought, but I now know that was true. I think I’m quite fast in vim now and using something different wastes up extra time always.

    I think you did not try long enough. However, I’m on the opposite trip now. I try (for the 2nd time, 1st try failed) using emacs to replace vim, now. Using it a few weeks I’m still much slower with emacs, but I agree to most of your points. I still think vi(m) is the fastest possible alternative if you just need an editor. But it’s beyond it’s capabilities to solve complex things as you can do with emacs.

  4. Ah, nice post. I’ve recently switched from vim to emacs.

    In case you haven’t yet figured out, emacs has support for XFT font rendering backend. It’s still in CVS though. Some distros include CVS snapshots of emacs, I’ve been using one for some time and it’s been pretty good.

    I’ve actually written a blog post about this a couple of weeks ago, take a look if you are interested (screenshot included!):
    http://amrmostafa.org/bearable-emacs-recipe

  5. It sounds like most of the problems you have vim are from lack of familiarity.

    I’ll take your points one by one:

    1 – ESCAPE key

    As many others have noted, it can easily be remapped to another key or combination of keys. Though, personally, after using vim for a while, I don’t mind, and prefer the standard behavior.

    2 – starts faster
    3 – uses less ram

    I agree that these are irrelevant on desktops and laptops today. Still an issue on handheld devices, though, on some of which at least vi is available.

    4 – more comfort on other environments.

    I don’t know about AIX, but on Sunos, Solaris, the BSDs, of course on Linux, the rescue environments are bound to have a standard vi… and you’re really not going to need all the features of vim (or emacs) to rescue your system (I hope).

    5 – more productivity

    I definitely found this to be the case when I switched from emacs to vim in 1989, and have never looked back. However, I was by no means an emacs guru.

    6 – syntax highlighting

    Sounds like bugs in the syntax highlighting scripts, not in vim itself. Perl and C syntax highlighting work great, for instance. I’ve rarely seen vim mess up on syntax highlighting, but maybe this is because I tend to program in languages that are easier to write syntax highlight scripts for (ie. ones that use curly brackets instead of whitespace to delimit blocks).

    Also, when the default syntax highlighting scripts are deficient, there are sometimes alternative highlighting scripts available. I know that’s the case with Python. Check vim.org for more options.

    7 – indentation

    If you don’t vim’s default formatting options, you can easily have vim pipe your text through an external command (like par-format, or any of a thousand pretty-printers). If you’re really homesick for the way emacs does it, I bet you could even pipe it to an open instance of emacs and have it do it for you.. :)

    8 – yank buffer managment

    Check out the yankring script:

    http://www.vim.org/scripts/script.php?script_id=1234

    9 – problems moving between files/buffers

    As many people have already pointed out, on this point you’re simply mistaken about how vim works. Also, there are a million scripts on vim.org that make file/buffer management much easier. Just browse through the most popular/downloaded scripts, and you’ll probably see half a dozen good ones on the first page.

    However, even if you insisted on the default vim behavior, it’s really not difficult to remember that :bufn goes to the next buffer, and :bufp goes to the previous buffer. And if you manage to forget, there’s always :help buffers. All of these commands could be mapped to a single key or a short sequence of keystrokes, should you find occasionally typing :bufn or :bufp too burdensome.

    10 – not being able to create a new top-level window

    Using tabs is good enough for me 95% of the time. In the other 5% it’s really not a big deal to just open up another process. Still, this is an area where it wouldn’t hurt for vim to copy emacs.

    11 – gqap

    See above regarding piping the text through an external program, if you don’t like how vim’s formatting works by default. Personally, I want to keep any and all programs far away from reformatting my code, except to reindent a block here and there, which vim does just fine (in my experience). But if I need more, I’ll just pipe my code through a prettyprinter.

    Finally, I’d like to invite you to #vim on freenode.org. There are lots of very experienced users and developers on there that can answer your questions and help make using vim a lot more pleasant. Also, check out vim.org for thousands of vim scripts and tips.

  6. Oops, I meant :bnext and :bprev (or :bp and :bn for short)… this is what happens when you rely on scripts like Buffer Explorer a bit too much :)

  7. I may be confused, but I just read the manual and it sounds like without :set hidden (which is NOT default) Vim definitely CLOSES files when you leave them. It maintains a buffer list of where you were, but unless you :set hidden it unloads the file. If you have unsaved changes it asked you to save them etc (again unless you :set hidden). You can especially notice this with netrw files (open a file over scp etc) it takes time to go back to the file without :set hidden and with it it’s instant.

    The buffer list will show an “h” if a buffer is loaded and hidden (again you need :set hidden for this) and if that “h” isn’t there then a buffer is not in memory unless it’s visible.

  8. Meh, I use Vim for Perl and Javascript programming and aside from very rare single ‘ issues, syntax highlighting and indentation is never a problem… V and > are nice for indenting blocks of code, autoindent rocks!! and it you need to turn it off :set paste! is easy enough to type to shut off the indentation. when I can Vyp and :s/oldtext/newtext/ to copy lines of text, who needs anything else. :D I use Vim with Screen so all most of the Emacs keystrokes clash with my bindings so… that’s that.

  9. Well, if you have something like this in Python it does not work:

    def test():
    print “hello”
    if a ==b:
    pass
    else:
    pass

  10. Use US international when programming. Most international keyboards are inefficient to program with (I’m used to norwegian). With US intl. you get all special keys with alt+gr, like æøå, and have easy access to [] and the like.

  11. I wonder which key combinations clashed screen and Emacs. If screen cmd key(Ctrl-A) bothered, I wonder why it didn’t bother you in bash.
    But, I use ‘screen -e^Zz’ since I rarely stop my process and free up Ctrl-A.

  12. You complain of having to reach for all the
    time , but it is easy to not have to do that — just use
    “imap”(key re-mapping for insert mode) to map a sequence of two keys(eg “fg”) to . It is easy to learn to type that two key sequence rapidly enough to trigger the invocation of .

  13. I just sent you a comment that got mangled.
    Try it again. You complain of having to reach for the ESC key in vim , but it is easy not to have to do
    that. Just use “imap” (key re-mapping in insert mode) to map a sequence of two keys(eg “fg”) to
    ESC. It is easy to learn to type that sequence of two keys rapidly enough to trigger the invocation of
    ESC.
    I love both vi and emacs. A blessing on both
    their houses.

  14. I will agree that there are things in vim that I do not like. I absolutely refuse to run vim in vi compatible mode. Using keys to move my cursor around is just so strange to me and really a little used feature since the arrow keys are available on 99% of the keyboards out there. However where VIM shines the most over emacs is in a X windows environment. GVIM really looks like a gui program emacs looks like you started it from a xterm. I agree that each one has its uses and its really a personal preference on what to use. I personally don’t like either one very much. I would prefer a simpler text editor as I rarely use any of the “advanced” features that emacs and vim offer. I know there is nano but I have never really warmed up to nano either.

  15. By the by, GNU emacs, at the very least, could perform regex-based search and replaces since 1987. I suspect this feature existed much earlier. But, proof only comes from one of my old manuals. :-)

    Bill

  16. As an emacs user gone vim (2 years ago), I don’t think you gave vim enough of a chance. However, that’s why we have options, use what suits you best.

  17. I used vim for probably one and a half years. It’s a great editor, and I really like the movement keys and chainable commands. However, after switching to Emacs for three months, I’ve begun to notice every one of those weaknesses of vim a lot more. Especially the one where your main register was so easy to be overwritten, that got me all of the time.

    However, it’s not like it’s a dichotomy. I’ve taken viper mode and have modified it in such a way so that rather than trying to override Emacs, it harmonizes with it. I’ve also implemented visual-select mode, so Emacs commands work with the perfectly, but it also brings a lot of the goodness of the feel of vim.

    Perhaps if (when?) I release it, we can and the holy war once and for all. :-)

    I think I will call it vi-harmony. Or something cheesy, perhaps a useless recursive acronym?

  18. Hey! EVERYBODY posts about Vim and Emacs! It’s always on! You’re not the first one.

    Like someone else said, 8 months is too early to give up, but it sounds like you haven’t tried. Your issues don’t add up. You’re still a vim newbie. This article is misleading because it’s uninformed and inaccurate.

    The big thing about vim is the command mode. Obviating the need for control keys for everything just breaks the keyboard out into a whole new world. Operations that used to take seconds now take sub-seconds (as fast as you can type) and a whole lot more operations are available. The only editor that could beat vim would be another editor that uses a command mode, but there aren’t any.

    Syntax highlighting plugins do often skip the laborious picky little exceptions that would slow down the interface on low spec machines. You can write your own.

    Indentation was originally designed for C but there are multiple indentation control mechanisms. Roll your own. It’s not hard.

    For ‘the paste buffer’ read ‘the default paste buffer’. If you want to pick and choose what goes into your paste buffer and what doesn’t you need to start naming your paste buffers. Vim’s doing the best job here.

    Vim loves having lots of files open. There’s buffers and windows and splits and all sorts of ways of controlling your file lists.

    You’re upset about not creating a new window because you haven’t figured out how to work with multiple files yet. I never need or want an additional window in vim.

    No-one uses gqap for formatting XML. It’s just not intended. You can set a command to call an external formatter if you need to. This particular issue really reveals how little you’ve got across what vim does. You are complaining that gqap doesn’t format XML? No one told you it would!

  19. Agree with many of your comments. I have been using Vim (and continue to us) for over a year. The syntax and indenting needs work. It’s adequate not good. I basically turned of indenting for HTML.

    And for those who say roll your own :( Who wants to deciper cryptic regular expressions where almost everything has to be escaped twice? And if it was that easy wouldn’t major filetypes like HTML, XML and Javascript be rock-solid by now?

    Still, I love Vim. I find editing on Vim is much faster than having to use the mouse or doing finger gymnastics that require 3 or 4 keys. I can easily switch between Apple and PC keyboards.

  20. There is a learning curve for the syntax highlighting.
    I’ve made a couple of simple ones for myself but haven’t tried harder.
    I haven’t noticed any problems with the HTML highlighting and I do use it a lot.
    With some other types they are sometimes documented as not covering specific complex parsing situations but that hasn’t troubled me.

    The indenting control is simpler, and can be done by setting some different options.
    Again, I’ve had no problems at all with indent control. I’m surprised you turned it off.
    What’s the specific problem?

  21. I digg Vim and Emacs. Both are great editors. Both do things differently. Emacs is a badass because you could just open a shell right there and reboot your unix webserver, then bounce back to your file you’re editing. Vim/Vi is good for editing files, system rescue/configuration. I sometimes even use Nano if I don’t feel like hammering the ctrl key or using command mode in Vim. Pretty much depends on what mood I’m in/what I’m doing.

  22. I use :
    alias em=’emacs -nw’
    that will run emacs in current shell windo with as few letters as ‘vi’.

    Also you can consider the viper mode.
    Emacs does vi ;)

  23. That’s because python syntax is _defined_ by indentation, so the indentation can obviously not be defined by the syntax. We’ve got a classic chicken-and-egg problem.

    Consider this example:
    if a == b:
    print “some text”
    print “some more text”

    How is Vim supposed to know whether the second print statement should belong to the if block or not?

    If you try autoindenting e.g. a file in C, XML or JavaScript however, Vim would correctly adjust the indentation to the syntax.

  24. As you get used to working in Vim normal mode, you’re not supposed to use either arrow keys or hjkl most of the time. You instead navigate a word at the time with w/b or W/B, a sentence at the time with ( and ), a paragraph at the time with { and }, or until next occurence of character ‘x’ with fx / Fx. See `:help cursor-motions’ for more info.

  25. I’ve been using vim for about a year now, since I finally found myself on a workstation where I really *had* to edit files over a console. And I found it pretty nice, but I have thought about switching to emacs, but never really took the dive.

    It’s good to see that you’ve run into pretty much the same irritations that I did, and that emacs really does handle those better. I’ve really wanted vim to work for me, but there’s too much stuff “out of the box” that just doesn’t work. I think a lot of vim users have adapted themselves to vim rather than the other way around.

    I might miss a few commands like :norm, but we’ll see.

  26. Try el-get and install vimpulse using it. Then you have vim like editing features (even text objects are supported) in Emacs.

  27. I was an Emacs-only user for about something less than 10 years. That was before my left little finger got injured (due to heavy use of Emacs in my daily professional programming life). I had to switch to vim. My finger was saved. I still do use Emacs just for debugging.

    Ask any heavy Emacs users about their left little finger experience.

  28. Actually, I stand corrected here. In the example I gave, my newest version of Vim is doing the correct thing, while Emacs doesn’t!

  29. When I first started using Linux I learned Vim. I had wanted to learn Emacs but something just wasn’t clicking about it–which was odd considering that Emacs is usually considered to be less intuitive.

    But occasionally I look at Emacs again and lately have tried using it to edit Haskell. Using Emacs really shows some of the weaknesses of Vim. The power of haskell-mode to automatically indent the code is amazing. In Vim I spend a lot of time hitting the tab key or << to move things around. Overall the Emacs user interface is more polished, I think–it has great tab completion, for example.

    On the other hand when I'm in Emacs I feel like I'm using Microsoft Word because it just takes so long to navigate the file. I'm using to navigating in Vim command mode, where everything is a few keystrokes away. With Emacs it seems to me I have to hit a lot more buttons. In Vim for instance I often use f or F to go to a certain character on this line. ";" repeats it. Maybe Emacs has an equivalent?

    My current impression is that one can be equally productive in either editor, just productive in different ways. I've liked looking at Emacs to see how it does things differently, and to see some things done so well, but I don't think it will actually make me more productive–especially not so much more productive that it will offset the time spent reading Emacs docs. I'd imagine the same is true for someone going from Emacs to Vim. It takes so long to get really proficient in either editor that, by the time you do that, it's just too much trouble to switch.

    I'm glad we have both these editors so each person can choose what is best for him or her.

  30. oops, at the top of my previous comment that should be “Vim is considered to be less intuitive,” with its bizarre modal thing. I think I found Vim’s documentation to be easier to understand.

  31. I use Emacs on my home machines, but tend to use vim on remote boxes. I’ve tried to love Tramp, but when connections time out it seems to hang Emacs completely. Life’s too short.

    Emacs is definitely more mainstream within the Haskell world, though :)

  32. I actually like that buffers have to be saved before moving on. It stops a whole class of mistakes that I could make while editing multiple files. You can have files saved automatically by using the ‘autowrite’ and ‘autowriteall’ config options.

    I highly recommend the BufExplorer plugin to manage your buffers too.

    And of course, mapping :bnext and :bprev to saner keybindings (I have Ctrl-Left/Right) will help you.

  33. Any strong feelings on vim-mode versus viper-mode for emacs?

    Also, the Kinesis Advantage keyboard solves the pinky issues, but after about 12 years of using it, I’ve started to get thumb issues, as the left thumb is what I hit the ctrl and alt keys with. Has this happened to anybody else?

    Thus, I’m toying with going to vim like bindings to ease the work on my ctrl-key thumb….

  34. “since Esc is a farther reach than anything in Emacs, and let me tell you, you’re hitting Esc all the time in Vim.”

    This is absurd. What made the author think he was required to use Esc at all? Just remap practically any keys (within Vim) you like to Esc and problem solved. I use jj. Switching between normal and insert mode is so fast the editor essentially feels modeless.

    I have no opinion on which editor is better overall (and I’m not a coder so my opinion is worthless here anyway) but people who bash Vim because of the alleged need to use the Esc key simply don’t realize how easy it is to customize Vim to your liking.

  35. gqap is the wrong tool for indenting XML, by the way, it’s intended for prose.

    Actually, it’s the right command, but the wrong text object. You probably DO want either gq or =, however you want to operate on the current XML tag. You’d do this with gqat or =at.

  36. Ctrl-c (and others) will do the same as Esc.

    :e something and then Ctrl-o to go to last edit location until back in previous file

  37. I think that both emacs and vim are damn good and powerfull editors, and both are good to the extent ones knows how to use their features. Aside from that, it is natural that some will feel more confortable with one and less with the other. We are different. :)

  38. I think your arguments are not that great. For example, you think that the only way to exit insert mode is to hit . You can map the key to do that for you.

    A more valid critique would be “why not have ‘jj’ carry out this role by default since is much more comfortable than .

    There are other even bigger problems. One that comes to mind right now is with word wrap. When you wrap words, the go all the way off the right hand margin and show up on the left hand margin. This is great for plain text documents, but if I have a nested structure (think if-else) which is tabbed, I want the wrapped text to be correctly indented. This is especially a nuisance for LaTex. There is, AFAIK, no possible way to do this with vim.

    It’s best to think of Vim as the world’s coolest Regular Expression. No other Regular Expression will ever come close to it. However, it is not a Context Sensitive language. Therefore, there are some things it can not do.

  39. I have been using both vi and emacs for more than 20 years, so the difficulty of learning, the choice of keys and most other issues discussed here are no longer important. Until recently, I had been doing most of my work in emacs, using vi as a sidekick, often doing bizarre things like editing my .emacs. Don’t laugh; it is simply easier to type ‘vi ~/.emacs’ than ‘c-x c-f ~/.emacs’. Sometimes my choice of the editor is totally random. They are basically equivalent.

    The problem is, the emacs-world and the vi-world have substantial islands of non-overlapping functionality. It just happens that nobody in the emacs universe cares about javascript. The only sane javascript mode, js2-mode, does a decent job of highlighting the local syntax, but indentation is hideously inconvenient and ecb has no support for javascript at all. Which means I can’t work on large projects. I still do all my c work and perl work in ecb, but because I make a living coding in javascript, I had to abandon emacs and go into a year-long macvim session.

    Fortunately, TagList does a pretty good job marking up javascript. It, too, does not properly understand the language, but at least it does not break and creates reasonably good overviews for my files and (some) functions therein. Indentation is perfect.

    Emacs has become a frontend to subversion. And this reversal of preferences has occurred simply due to an accident. One of the most popular programming languages simply failed to jump the adoption threshold in emacs-world.

  40. Regarding hitting escape all the time, imap jk and you can just hit jk in insert mode instead.

Leave a Reply

Your email address will not be published. Required fields are marked *