So long, Vim. I’m returning to Emacs

November 1st, 2007

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 </ that it moves left and if it starts with an opening tag, that the next line moves right. But it’s not smart enough to do this reliably. Not only that, but indentation is not handled with consistent configuration between languages. And even though Vim ships with a ton of language modes, the central docs only cover indentation for C.

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 </para> 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.

Categories: Software

Tags: , , , Leave a comment

Comments Feed104 Comments

  1. Ben

    Vim can do [b]dt[/b] across lines: use [b]d/c[/b] to delete to the next character c. (And of course this can delete to an arbitrary pattern rather than just a single character like [b]dt[/b].)

    I pretty much agree with the rest.

    Ben.

    Reply

    John Goerzen Reply:

    Right, the whole paradigm in Vim is really nice. I wish Emacs had that sort of idea pervasively as well.

    Reply

  2. nate

    I donno.

    I tried
    print “Hello\”"
    in a python file…
    and that worked just great. It’s ‘always’ worked as far as I know.

    Vim will do different sorts of syntax highlighting based on whqat type of file your dealing with.

    If I just open up a file with no extension or anything like that, just plain text, then syntax highlighting obviously doesn’t work with the “hello\”" example.

    By default a lot of Vim’s mode-detection stuff is disabled. Maybe that’s the issue.

    Then with the autoindention stuff.. it’s brilliant.

    Many many times I’d be editing a file or something like that and all of a sudden the ‘auto indent’ seemed to go all funky on my ass. It didn’t work, it did stange things… Then I examined the source code and realised that I had missed a ) or a : or something important like that, and that the auto indent was the one acting correctly while I wasn’t.

    I thought it was odd that you’d complain about this since both the highlighting and auto indent worked so well for me.

    Although this is all using python mode. I am more then willing to accept that there is large variations in quality between different language’s syntax support.

    Reply

  3. Steve

    What was your issue with using multiple buffers with “set hidden”? I don’t know of any criticial distinction between using hidden mode (which should be the default IMO) in Vim and managing multiple buffers in Emacs — to me they are functionally equivalent. Personally, I never use split windows. You may find one of these filesystem/buffer management plugins useful:

    LustyExplorer — [url]http://www.vim.org/scripts/script.php?script_id=1890[/url]
    fuzzyfinder — [url]http://www.vim.org/scripts/script.php?script_id=1984[/url]

    Reply

    John Goerzen Reply:

    I can’t be certain, because I sorta gave up on it awhile back and just used multiple gvim instances, but I THINK these were the issues:

    :n, to access the next file given on the command line, still wanted to close the current file. ISTR that :e didn’t do the expected thing either, but I think there was some 4-character command that did what I wanted, but could never remember.

    Reply

    Steve Reply:

    I don’t think these commands behave this way, at least in my configuration — however, I can certainly understand being frustrated with the awkward :e, :n, :prev, :b* interface.

    If you feel like giving Vim another shot in the future, I do recommend one of the above plugins (or one of the many other similar plugins). They provide much more “emacsy” buffer management, very similar to find-file and iswitchb-mode. (Which are simply better than what Vim has to offer in a plain install.)

    Reply

    ktr Reply:

    Hey – I understand your frustration with the buffer thing in vim. Long time back though I discovered the following mappings and stuck them in my .vimrc:

    nnoremap :bnext
    nnoremap :bprevious

    Then you can essentially hit “Ctrl-Tab” and “Ctrl-Shift-Tab” to switch between buffers. So if you’re editing one and need to do something quick in the other just “:e other_file.txt” as suggested, edit it and then hit “Ctrl-Tab” to go back (or better yet, if you’re really done with it hit “:bd” to delete the buffer you just opened since you’re now done with it).

    Also, in Vim 7+ try “:tabe” which opens up a file in a new tab. Then “gt” or “gT” switches forward and back (respectively) between tabs.

    John Goerzen Reply:

    I stand corrected. I have checked, and :e behaves as you stated under set hidden.

    Brice Reply:

    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.

    Reply

  4. John Goerzen

    It may be that Vim’s Python mode is as good as the Python mode in Emacs, but I just didn’t do much Python work during the time I used Vim. The modes I did use regularly were certainly not as good as the ones in Emacs. What you describe for Vim’s Python mode sounds like what I expect out of every language in Emacs, including markup languages and other more obscure ones. Quite frankly, I expected it out of Vim going into the project too, and was disappointed to discover that the Vim modes were not consistently high-quality.

    Reply

  5. Alpha Chen

    With autoindent on, =[range] will reindent based on the language. I often wind up using =% to reindent a function after I’ve refactored it.

    Reply

    fladd Reply:

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

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

    Reply

    Anonymous Coward Reply:

    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.

    Reply

    fladd Reply:

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

  6. Daniel Wagner

    On hitting Esc — have you tried Ctrl-[? This can be really quite convenient if you remap CapsLock to Ctrl, as your hand doesn’t even need to leave the home row.

    On opening many files — have you tried :tabnew or :tabedit?

    On formatting with gq — paragraphs are defined in a strange way in Vim; all consecutive non-blank lines are in a paragraph. If you just want to reformat the line, you could use gqq instead.

    Lots of love, and have fun back in emacs,
    ~d

    Reply

  7. Sindisil

    Perhaps I’m just not understanding what you want to do, but :e in vim will just open a new buffer with the new file in it. The old buffer is still there (:buffers to display all buffers). You can switch buffers at any time, no split required. In vim splits and buffers are orthogonal. You can have multiple split panes open on a single buffer, or have each pane be a view on a separate buffer.

    Reply

    John Goerzen Reply:

    Check the vim manual.. :e really closes the current buffer. It may remember where you were, but it wants you to save before switching. I want to have multiple ones open at the same time.

    Reply

    Steve Reply:

    Hi John, that is only the case if you are not using “set hidden”. For anyone using Vim as a development environment, this is pretty much a mandatory option.

    Reply

  8. Dave

    You bailed on vim too early. Vim is kind of like Spider-man. Only with Spider-man the qualifier is responsibility, with vim it’s a steep learning curve.

    Your complaints seem to be that vim doesn’t work for you out of the box. That’s not a reason to dump it. Vim is infinitely customizable, but it just takes time to figure out how.

    For example, the Minibufexplorer plugin solves two of your problems.

    Reply

    John Goerzen Reply:

    The *biggest* problem is the indentation in Haskell and XML. I have searched extensively for solutions to that. Yes, I *could* write my own, but learning how to do that — and getting it done right — would wipe out any productivity gains I’d get from using vim for maybe the next couple of years or more. Not worth it to me, when Emacs has working indent modes for every language I try.

    I have tried to avoid using too many nonstandard plugins, both in vim and emacs. Hard to maintain when you work on lots of machines, may not be updated when vim is, etc. I did use the nonstandard Haskell mode in vim, which helped, but I believe I limited myself to that. I use the Debian haskell-mode package in Emacs. (I don’t mind them if they’re in Debian packages, because then they can be kept up-to-date automatically)

    So yes, I accept that plugins could help some of this. But not the biggest pain.

    Reply

    RichiH Reply:

    There are various scripts to keep your VIM runtime up to date. Also, using the VCS of your choice to keep your RC files in one handy bundle should be pretty much standard, these days :)

    Reply

  9. VALERA

    Emacs 23 will have antialised fonts.
    Ubuntu packages for CVS version available here:
    http://peadrop.com/blog/2007/09/17/pretty-emacs-reloaded/

    Reply

  10. Knower

    Emacs 24 will run Skynet.

    Reply

    John Goerzen Reply:

    What is Skynet? Google turned up a bunch of hits, but none seemed relevant.

    Reply

    Kyle Reese Reply:

    Defense network computers. New… powerful… hooked into everything, trusted to run it all. They say it got smart, a new order of intelligence. Then it saw all people as a threat, not just the ones on the other side. Decided our fate in a microsecond: extermination.

    Reply

    tgrasp Reply:

    To see it in action, watch any of the Terminator films…

  11. Adonikam Virgo

    I agree with all of the problems listed with vim. As has already been said, the flexibility is there to fix some things quickly. Unfortunately at the point when it comes to the scripts which control syntax and indentation the learning curve is undefined.

    I am currently working mostly in Java, XML and PHP. Though I have hacked a solution together to syntax-highlight PHP and XML in the same document and find the indentation sufficient for my purposes, I frequently find myself working around the automatic indentation. Though I must admit the temptation to “give up” is real, the religious fervour in me assures me that a few more lines in ~/.vimrc will solve all my problems, if only I could find the right tip. Perhaps someone needs to contact the xml.vim maintainers and get it fixed once and for all!

    When I worked in Haskell last year, I do not remember having smart indentation on at the time, and I was only writing small programs, so I was quite comfortable. However, the popularity of the language is such that I concede that it may be a long time before an intelligent indentation script is written, unless a friendly emacs convert comes and helps out. :)

    Reply

    John Goerzen Reply:

    Yeow, Zing! ;-)

    Actually, Python borrows heavily from Haskell syntax in a lot of ways. I wonder if someone hacked up the Python mode a bit…

    Reply

  12. miran

    When you open a file with :e it doesn’t close the file you’re working on. It keeps it in a buffer. You can switch back and forth between full screen opened files with :bn, :bp, :b or :b

    Reply

  13. Reid

    I’m a hardcore Vim user, and it’s true, Vim doesn’t understand the syntax of most languages at a deep level. I think that’s because the vim script/configuration language isn’t really all that powerful, and its easier to parse in elisp. Lisp in general is pretty good at that stuff. As a consequence, syntax highlighting is alright, basically just all the keywords and not much more. Indentation also sucks for languages like Haskell with subtle indentation patterns. Python is simple, do a new indent on lines after a line ending in :. Vim also has good indentation for Scheme/Lisp, which are also pretty easy to parse.

    I think your other complaints are fixable, but I agree that the above is a real fault in Vim.

    Reply

  14. Anonymous

    I know that vim should probably take things into account, but if the language has a difficult syntax to highlight, then that language has a problem. Vim should do it yes, fine. I found that finding which option to change to simply activate fontlock, (which apparently means syntax highlighting) for emacs far to annoying. To me, vim has a short learning curve. With emacs, there’s so much crap, it’s hard to tell what it is you want to know.

    Reply

  15. Juri Pakaste

    Re: autoindent, I’m a long time Emacs user but I really miss vi-style dumb, non-syntax aware autoindent every time I end up using a less than polished language mode. I have my own set of functions to do sorta kinda the same thing, but they aren’t really good enough, at least yet, to publish.

    Reply

  16. The Changelog

    Yesterday’s post about switching back to Emacs saw quite a few comments from people (most of them useful, even). I learned a few things.

    My biggest gripe about Vim was that for the file types I worked with most, its indentation and syntax highlighting

    Reply

  17. Lionel Barret

    NEVER USE ESC !
    Use the ctrl+c instead !

    Reply

    CY Reply:

    Or use Control-[ instead if you really need to press escape.

    there are slight differences between Control-C and Control-[

    Reply

    mantaar Reply:

    What the hell are you guys talking about? Is it really that bad? Can’t programmers google anymore? Swap Caps and Escape insensitive clods. Here’s the xmodmap to do that:

    ! swap caps and escape
    remove Lock = Caps_Lock
    keysym Escape = Caps_Lock
    keysym Caps_Lock = Escape
    add Lock = Caps_Lock

    You can do the same thing for the linux console with this:

    keycode 1 = Caps_Lock
    keycode 58 = Escape

    Indentation works in vim for everything but Haskell. Have you tried :filetype indent on yet?

    I’ve been a former Emacs user myself, changed to vim a year ago after my RSI… it *helped*!
    But, to be serious, both suck. Vim’s major flaws are: it’s folding is just plain broken. It just doesn’t work reliably. And using this half-hearted vimscript thing as a backend was a wrong decision. Having a complete language to back your editor configs up (like emacs) would be waaaay better.

    One *very* nice thing about vim is the eclim-plugin – vim-integration to eclipse! Yay!

    Reply

  18. troels

    One thing, which really set me off, using vim is, that I’m using a non-US keyboard. For regular characters, things are the same, but specialchars are placed at different locations, some require pressing Alt Gr. This means that a lot of the standard commands (For example, pressing Ctrl+[ is rather awkward) aren’t as “home-row” as they are sold as.

    Oh, and as mentioned, Emacs 23 has smooth fonts. Highly recommended.

    Reply

    Henrik Reply:

    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.

    Reply

  19. Andreas Krey

    M-x viper. I can’t imagine (well, I can but I won’t) using emacs without it. I switched from gvim because the installation I had to use at that time crashed once too often, and I gave emacs a chance. But not without the vi emulation.

    Reply

  20. John Reese

    Since vim 7, you can use :tabnew (and other assorted commands) to open up new tabs, each of which can have multiple windows. Map this to keys, and you have a much better way of working with multiple files at once.

    And :e does *not* close the previous file. That file is still in a buffer, and you can switch between buffers using :b#

    Cheers.

    Reply

  21. Rohan

    I think you need to spend a little more time with the vim tutorial – as the previous commenter mentioned – :e doesn’t close the previous file.
    The messing with the paste buffer thing is totally true though.
    Personally I think it really depends on what you’re looking to do and how familiar you are with Unix systems. I think this site breaks it down nicely: http://comparati.com/1084-vi-vs-Emacs

    Basically – have some time to spare, and know Unix well? Use Vim. Else – Emacs.

    Reply

  22. Sam Vilain

    Did you get to try M-x viper-mode ? Best of both worlds IMHO

    Reply

  23. Lucio

    You can C-c instead of Esc, too.

    Reply

  24. jrib

    Swapping escape with CapsLock is a must for vim. Try it, you’ll never go back.

    Reply

  25. Onion Knight

    Hello. Though I haven’t read all of what you wrote yet, I’d just like to say that Control-[ has the same function as Esc in gVim.

    Reply

  26. Mikael

    Automatic indentation of blocks can be done with the visual marking and the == command.

    I have this line in my .vimrc because I tend to use it quite much:

    map ==

    I do agree with the paste buffer thingy though. Although I’ve gotten quite used to it after a couple of years of Vim abu… use. :)

    Reply

  27. Ram

    VIM sucks……….
    Emacs Rocks…..

    Reply

  28. Michal

    CTRL-6 (or CTRL-^) switches between buffers.

    And you can switch a particular buffer by typing the number of the buffer first.

    eg. 3 CTRL-6 for the 3rd buffer.

    :ls
    lists open buffers

    Reply

  29. Brian Meidell

    I agree and understand most of your criticism, except (as already mentioned by others) the :e behavior.

    I would like to mention, though, that I didn’t really become comfortable with vim until after 3 years or more, and now after 7 years, I am very comfortable.

    Some of the things you mention, like hitting the esc key a lot, is something that goes away.

    Other than that, your article inspired me to try and give emacs a shot again – I doubt I’d change, but I think I’ll give it a shot like you gave vim, and see if the migration the other way is easier.

    Thanks for a good article.

    Reply

  30. Jonathan Haddad

    I actually just went the other way – from emacs to vim. I found emacs tabbing to be completely insane, and I was never able to find a solution. I LOVE how vim handles tabs. It’s indentation is excellent.

    I’m using these, which I think did the trick:
    set smarttab
    set cindent

    Reply

  31. Ronald Duncan

    I have to admit that I gave up on EMACS in the same way as I originally gave up on vi.

    I really like the navigation with vim/vi, the issue is being able to use it everywhere.

    At the moment I am using visual studio a lot and ViEmu is a great help since it allows me to stick with some of vim, and use the IDE.

    And your point about the syntax and indenting is spot on for c# and SQL files. However gg=G works great under ViEmu at sorting out the mess, and vim is better than Visual studio on SQL.

    Regarding program size etc. vi is still much better than vim and the only thing in my view for massive files.

    Going to try out EMACS again in viper mode.

    Thanks for a sensible debate!

    Reply

    Ronald Duncan Reply:

    Just installed emacs and tried it out on re-indenting some SQL.

    WHAT A NIGHTMARE!!!

    It was a complete joke just kept shifting to the right and never came back.

    vim is much better for SQL, but still has some nasty bugs.

    However, It is probable that if I had a clue about emacs it will be possible.

    The SQL integrated editor in emacs looks really nice. Not managed to get it working yet. The vim plugin had a much worse UI, but did connect to the database.

    Looks like this could take a while. However viper does reduce the learning curve drastically.

    Since gg=G worked to reformat the code. It was a total mess so I researched found. C-x h C-M-\ and got the same mess.

    Vim took the mess and sorted it back out again, and worked with the original file.

    However using viper and C-z to switch between normal and emacs mode is nicer than using esc, and emacs is a lot prettier.

    :)

    Reply

  32. Chad Versace

    I’ve been considering making the switch to Vim due to peer pressure, and was about to make the leap next week. But I was procrastinating due to a suspicion that Vim would suck at Haskell. Thank you, you’ve saved me from much wasted time in VimLand.

    Reply

  33. laddiebuck

    A quick note from a vim user — I won’t defend it where I know its shortcomings. I know that indentation and gq suck. But I still prefer it because it’s very efficient, and no, I never touch the damned Escape key. (Not that it’d be practicable either, as in my xterm, there is a slight delay before it takes, because Esc is the same as a Meta- prefix to it). I just use C-c. It’s very fast and my hands hardly move in a vim editing session. It behaves like Esc in all but one case that I know of (multi-line insertion, which I think emacs doesn’t have, incidentally), but you can easily remap it in your vimrc.

    I use vim because it’s the most programmatic text editor, the one that best combines a user interface with a simple rule language, and it’s thus naturally suited to writing code. Even despite the indentation.

    By the way, you are incorrect, there is actually a way of re-indenting a document (just gg=G, no colon), but the indentation is definitely less polished than in emacs for most of the new-fangled languages.

    Reply

  34. Mario

    There is another way to do Esc. CTRL+[. Sometimes it’s faster than ESC up in the corner :D.

    Reply

  35. Sam

    Comfort of typing:

    I set Caps Lock to be an *extra* Ctrl key. If I want all-caps, I change the case after I’ve entered it, with gU(motion). Yes, that’s right, I’m using Vim, and I’d rather have an easy-to-reach Ctrl key than an easy to reach Escape key.

    Why? Because ^[ is easy to type, and I *love* Vim’s completion. I know Emacs has M-/, but it’s not as good. In gVim 7, when something has multiple completions, it shows you a dropdown, so you can see how close you are to the one you want. And that’s not even getting into the ^X stuff…

    Highlighting and indentation:

    Which editor does these best varies between filetypes, but when Vim gets it wrong I don’t find it too troublesome. ^T and ^D fix indentation (as long as you’ve set shiftwidth appropriately), without leaving insert mode.

    Your issue with deleting tabs it shouldn’t be inserting sounds like a misconfiguration. I don’t think I’ve run into it. If by “the insertion of Tab characters is disabled”, you mean you’ve set expandtab, then I don’t know how it’s happening.

    Unfortunately, indentation doesn’t work in bird-style literate Haskell, ‘cos the arrowheads mustn’t be indented.

    The paste buffer:

    I like the way it works on the Mac version. The standard Mac clipboard keys (Command+X/C/V) use the “+ buffer, which is shared with other apps, and the standard Vim keys work the standard Vim way, and don’t interfere with other apps.

    Multiple files:

    I’ve got a mapping for “:ls<CR>:b<Space>”, which shows me a list of buffers, and I just enter the number of the one I want to switch to. I also use CTRL-^ a lot.

    No multiple top-level windows:

    Yeah. That’s my biggest gripe. I should have another look at the tabs feature sometime soon.

    gqap:

    I tend not to use that. Some of the files I edit have rather… idiosyncratic ideas of what constitutes a paragraph, so I just gqj, and then dot my way down. I tend to do that even when I think gqap would work, just because I like watching it.

    @Adonikam Virgo, on bilingual files:

    I have a mapping (actually a bunch of autocommands that remap the same thing) to switch between each pair of filetypes I want in one file. So it toggles between lhaskell and tex, for instance.

    @troels, with the foreign keyboard.

    So remap Ctrl+some foreign key.

    Reply

  36. Sam

    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!

    Reply

  37. Brandon

    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.

    Reply

    donh Reply:

    It’s not as powerful as dired, but try :Sex in vim.

    Reply

  38. Brandon

    I’m sorry, I meant move over *from Emacs.

    Reply

  39. toaster

    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.

    Reply

  40. Amr Mostafa

    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

    Reply

  41. Lapinski

    i saw your post when i was googling the xml indentation issues in vim.

    and turns out i found the following tip which probably solved the xml indentation problem you couldn’t find a solution:

    http://vim.wikia.com/wiki/Format_your_xml_document_using_xmllint

    this tip was created back in 2002, so maybe you missed it when you did your search?

    Reply

  42. aaa

    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.

    Reply

  43. aaa

    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 :)

    Reply

  44. Christopher Giroir

    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.

    Reply

  45. John D Jones III

    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.

    Reply

    Raymond Chung Reply:

    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.

    Reply

  46. mike legan

    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 .

    Reply

  47. mike legan

    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.

    Reply

  48. Steven

    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.

    Reply

    Anonymous Coward Reply:

    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.

    Reply

  49. Bill

    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

    Reply

  50. anon

    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.

    Reply

  51. Tim Harper

    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?

    Reply

  52. AnilG

    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!

    Reply

  53. rick

    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.

    Reply

  54. AnilG

    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?

    Reply

  55. Andy

    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.

    Reply

  56. Nicolas

    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 ;)

    Reply

  57. the fish epic » The world, through Vim

    [...] been poking around in Vim all morning, I’ve come across a blog post of someone who has done something similar. I think I’ll run into pretty much the same gripes — [...]

  58. Ben

    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.

    Reply

  59. Ardi

    iam Emaniacs.

    Reply

  60. Marc Weber

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

    Reply

  61. Alex

    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.

    Reply

  62. Omari

    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.

    Reply

    Charles Reply:

    Search for Evil mode on emacs. The best of vim with the power of emacs.

    Reply

  63. Omari

    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.

    Reply

  64. Mark Wotton

    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 :)

    Reply

  65. Justin Gordon

    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….

    Reply

  66. BC Armstrong

    “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.

    Reply

    John Goerzen Reply:

    Perhaps, but it’s broken by default, and not mentioned in the introductory tutorials I had read at the time.

    Reply

    SciK Reply:

    You can remap Caps Lock to Escape at X level, just like you do with Emacs and Ctrl.

    Reply

  67. Ben

    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.

    Reply

  68. nik3daz

    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

    Reply

  69. Fernando Basso

    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. :)

    Reply

  70. pukster

    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.

    Reply

  71. Gene Selkov

    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.

    Reply

  72. Information Overload » Blog Archive » Vim continued (sortof)

    [...] However, as much as I liked vim, I did have a number of things about it that really bothered me.  First and foremost is vimscript. To me it just feels really half baked and extremely domain specific.  If I’m going to have to learn/use a language to configure my editor, at least make it a cool one like lisp that can actually be used elsewhere.  While you can configure vim using other languages, as this post indicates, it is not without its pitfalls.  Also, I found myself agreeing with posts like this. [...]

  73. Dennis

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

    Reply

    Dennis Reply:

    Blog ate my brackets, that’s imap jk (open angle bracket)Esc(close angle bracket).

    Reply

  74. Duckie

    Hello

    I think several of your arguments are not really relevant:
    - About the RAM : since in fact, it does not have any impact on a desktop personal computer, it does when you share a network development machine with several developers. We got this problem in my team about emacs.
    - About the fonts : I dont know how you use emacs but when I use it, wether from Windows in putty or on linux in a terminal, I do have anti-aliased fonts, because it depends on the terminal, not the editor.
    - Top level X Windows : Same thing. Gvim is awful, small wonder it doesnt fit your needs. To enjoy a real vim experience, Xterm or Gnome terminal will do nice.

    Reply

    Roger S Reply:

    Back in 2007 (when this blog post was originally written – that’s right, *6* YEARS AGO) the Emacs GUI (he’s not talking about the terminal) did not have support for anti-aliasing fonts. Now it does.

    Reply

  75. Luca Bruno

    Are you still using emacs? I’d like to point you to a new incoming: http://vanubi.github.io/vanubi/

    Reply

Leave a comment

 

Feed

http://changelog.complete.org / So long, Vim. I’m returning to Emacs