Vim vs. Emacs (Part 1)

So about a month or so ago, I decided that I needed to start learning a command line text editor. XCode, the editor I had been using for Python files, didn’t work very well with the new version (in particular, the essential plugin that I’d been using to clear trailing whitespace on save doesn’t yet work in XCode 4). I’d been using TextWrangler for other things, and started to switch to it for Python editing too. As far as free GUI text editors on the Mac go, TextWrangler is the best.

But I’d seen some of the nice features that vim has, like automatically keeping all lines under 80 characters, on a friend’s computer, and I decided that I should try it.

Now, I had had a little prior experience with both vim and emacs, but all that I remembered was for vim that i inserts and ZZ quits (for when I accidentally open it) and for emacs, that M-X doctor starts the psychiatrist.

So I’ve decided to try them out, doing it cold turkey. To make sure that I choose the better one, I’ve decided to try both. So, starting about a week ago, I’ve been using nothing but vim for all my text editing. Starting in January, I will try using emacs, and after two weeks, I will see what I like better.

My opinions so far on vim:

  • The tutorials suck. The best tutorial is vimtutor (type that in the command line), which I think comes with vim. It’s not bad, but it leaves out a few things that I would consider to be essential to a tutorial, for example, how to scroll (answer: use CTRL-D and CTRL-U). I started the emacs tutorial a while back, and while I never finished it, from what I remember, it was much better (and I also remember that the first thing it talked about was how to scroll by more than one line at a time). It also left out the . command, which I think is rather useful. I did print out this cheatsheet and have it sitting next to me on my desk. That has helped a lot. I hope I can find something similar for emacs when I get to it.
  • vim is too line oriented. vi started out as an extension to ed, the line editor, so this is not surprising. But I still can’t understand why pressing l at the end of a line can’t bring me to the beginning of the next line. Maybe I’m just still doing it wrong (supposedly, you should rarely use h and l over more efficient moving commands).
  • Somewhat related to the last point, vim really likes to ring the terminal bell a lot. To quote Wikipedia, “vi has two modes – ‘beep repeatedly’ and ‘break everything'”
  • I managed to customize it to the point of usability (there are still several things I need to go in and figure out how to fix). See https://github.com/asmeurer/dotfiles for my .vimrc and .vim/ files. I found a decent Python syntax file, but it’s actually not that great. I modified it to color single quoted strings different from double quoted strings (a feature I missed from Xcode). I still need to make a better color scheme (preferably the same as Xcode’s midnight), but this is enough work that I’ve put it off.
  • Pressing ESC all the time is really annoying. Sometimes, I just arrow over, even though I know you’re not “supposed to”, just because my fingers don’t want to reach over and press ESC. I’m also really used to using control sequences to move around while typing, which of course doesn’t work in vim. In fact, so far, I’m suspecting that I’ll like emacs better. But I’ve vowed to give both a fair chance. But so far, my impression is that vim is a great for text editing, but not so hot for text writing (unless you always write text perfectly, so that you never need to leave insert mode until you are done typing). Just the simple act of deleting a mistyped word (yes, word, that happens a lot when you are decently fast touch typist) takes several keystrokes, when it should in my opinion only take one (two if you count the meta-key).
  • The customizability is really nice. So far, everything that I’ve thought of to change has been changeable. Also, language is easy enough to understand that I was able to modify the Python syntax file without any difficulty.
  • I like how it syntax highlights virtually everything I throw at it.
  • If there are any vim experts out there reading this, I have some questions:

  • Is there an easy way to get a list of and jump to a function/class definition in a Python file? In Xcode and TextWrangler, there was a nice popup at the top of the window that I could access these from. In vim, so far the best I’ve found is searching for it, which isn’t very efficient.
  • I got TAB to indent 4 spaces in Python, but for some reason, when I create a new line after a :, it puts 8 extra spaces. I wouldn’t be surprised if this is the result of some mismatch/error in my .vimrc or .vim/ files, but I don’t know how to fix it
  • Any useful tricks to share? Especially for editing Python files.
  • How long did it take you to become reasonably efficient with vim?
  • EDIT: I thought of some more questions:

  • Is there a way to make vim consider camelCase to be word boundaries?
  • Finally, if anyone else is thinking of starting vim, I have some useful things I’ve already found in my .vimrc. So you might take a look at that, and add the ones that you like to your .vimrc. Finally, if you are on Mac OS X, you should use iTerm2. Actually, you should use this regardless of what text editor you use. It’s a very good Terminal.app replacement that has virtually all the features (with a couple of exceptions) as Terminal.app, and a ton of extra ones. The one I want to mention here is mouse reporting support, so you can use your mouse to do things in vim. This is very useful, as sometimes, e.g., when selecting text, using the mouse is just more efficient. Also, if you get frustrated trying to remember the commands that will move around you faster than h, j, k, and l, you can just click on where you want to go.

    :wq

    19 Responses to Vim vs. Emacs (Part 1)

    1. Scott says:

      The first thing you might consider, both for Vim and for Emacs, is keyboard key reassignment. For Emacs you will want to swap the control and caps lock keys, and for Vim you will want to swap the escape and caps lock keys. This will dramatically change how it feels to use these two editors. Being able to hit the escape key with the pinky of your your left hand without moving away from the home row in Vim allows you to touch type this key like any other. It is used so often in Vim that this is really a requirement for efficient editing. Doing so will virtually eliminate the issue you have with escaping to command mode to move around and delete words. By the way, when you want to delete a misspelled word, try the command daw (delete around word), diw (delete inner word). The first will delete the word and the white space around it. The second will leave the white space intact. Better still, use caw and ciw, for change around word and change inner word, which does the same thing, but leaves you in insert mode to type a word’s replacement.

      Secondly, memorizing all of these commands is daunting. There is one thing to know and one thing to do to overcome this problem. The thing to know is that Vim’s commands are a mini-language of nouns, verbs and modifiers. Movement commands such as w, W, b, B, e, E and bigger ones like (, ), {, and } are nouns corresponding to text objects. Action commands like y, yy, Y, d, dd, D, c, cc, and C are verbs that act on nouns, and numbers are the modifiers that multiply either nouns or verbs any number of times. The way these commands are used is generally [modifier] verb [modifier] noun, without spaces, the modifiers being optional.

      The thing to do is to make your own cheat sheet. Don’t rely on someone else’s. Inevitably the cheat sheet will be too large to be useful. Make your own and only put on it what you need to remember right now.

      Often overlooked by new users: the Vim user manual. The documentation is split into two parts: a reference manual, which is encyclopedic, and a user guide, which is based on a published book and is a very good extended tutorial. To get to it, type :help usr_toc. Then use what you learned in the vimtutor to navigate it. It reads like a book and explains things in human terms.

      I hesitate to go into more detail to answer some of your questions, because I feel you need to get some of the basics down beforehand. But there are Vim plug-ins that will give you what you want. The ctags plug-in will help a lot with finding function definitions, and there are additional plug-ins for working with Python.

      Go to vim.org and explore. There is a wealth of information there, especially in the tips section. Also, two excellent color schemes are Zenburn and Darkburn. You can find both at that site. Drop them into ~/.vim/colors and place “colorscheme zenburn” (or darkburn) into your startup file to use them.

      Two weeks is pushing it for a Vim trial, or even for an Emacs trial. You will find that Emacs is very easy to get started with, but will become harder to bend to your will later unless you are willing to learn its language. Vim is harder to start with initially, but becomes much easier after about a month, and its extension language and plug-in system are easier to use.

      More information is available on-line, too. You can find a good medium length tutorial at http://www.swaroopch.com/notes/Vim/ and some good video tutorials at http://vimcasts.org/ and at http://www.derekwyatt.org/vim/vim-tutorial-videos/.

      :wq

      • asmeurer says:

        Thanks for the suggestion about Caps Lock. I will use http://pqrs.org/macosx/keyremap4macbook/extra.html to remap it.

        Regarding daw, thanks for the tip. The difference between that and dw is subtle, and I doubt I would have noticed it without your suggestion (the difference is that daw deletes the whole word regardless of where your cursor is, whereas dw deletes the rest of the word from where your cursor is).

        I actually feel that I have gotten pretty good at most of the simple commands already, more than you are giving me credit for. Remember that I’ve been using it cold turkey for the past several days, and I do a lot of text editing. Please don’t hesitate to answer my questions if you know the answers. Those are things that I’ve already found problems with with my limited editing experience (they are not hypothetical, they are are real problems that I’ve encountered).

        And take a look at my .vimrc and .vim/ directories that I linked to to see what I’ve already done as far as plugins. I’ll check out those colors you suggested, but I think today I am going to just buckle up and create my own scheme. It’s apparently very easy, and I’ve already found one that is pretty decent (the built-in slate), and I have in mind what I want (XCode’s midnight). By the way, do you know if it’s possible to choose different colors for the text depending on if it’s highlighted or not? Right now, several things highlight text (spelling, searching, etc.), and the highlight color invariably conflicts with some text colors, making it impossible to read the text. I’d like to keep highlighting for some things (searching at least; I think underlining for spelling should be fine), but it’s very difficult to pick colors that don’t conflict with anything. The same goes for highlighting in visual mode.

        Regarding the cheat sheet, actually, the one I am using seems to be pretty good. If anything, it is too small, not too large, as I often have to look up the extra commands (like things proceeded with z, ], or :). I’ve got a pretty good memory (if I didn’t, I think no command line editor would be fit for me).

        Regarding the length of the trial, perhaps. The main reason I am making it so short is that I want to become moderately efficient at whichever one I end up using before my classes start again in January, where I will not have as much free time to go cold turkey on a new style of text editing. I may end up giving the trial for each more time after two weeks with emacs. It depends on where things stand at that point, if one is a clear winner or not.

    2. Scott says:

      These two URL’s will help with camelCase. The first is a Vim tips page with settings that can be used to help and the second is a Vim plug-in that does it all for you.

      http://vim.wikia.com/wiki/Moving_through_camel_case_words
      http://www.vim.org/scripts/script.php?script_id=1905

      The taglist plug-in will help you browse functions. It works with exuberant ctags, so you need that installed for it to work correctly.

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

      These are my tab and indent settings. You can look these up in the documentation, but the two that work together to keep things consistent IIRC are shiftwidth and softtabstop.

      ” set tab and indent options
      set shiftwidth=4
      set softtabstop=4
      set smartindent
      set autoindent

      You should probably reverse the order of:
      t_Co and
      colorscheme

      in your .vimrc to ensure that colors are applied correctly.

      Some other tips you may find useful if you don’t already know about them:

      You can use autocomplete to help you write code. While in insert mode, start typing a variable or function name. Then press control-p, and Vim will fill in the remainder of the name. It must have already been used in your file for it to work.

      Visual block mode. Press control-v in command mode. You can use movement commands to create a rectangular highlight. Then use the c command to change the text. Type a replacement string and hit the escape key. The replacement string will appear on every line covered by the highlight and replaces what was highlighted.

      Insert mode is just another command. It can be given a numeric modifier. Whatever you type while in insert mode will be repeated when you escape to normal mode. For instance:
      80i*escape will enter 80 *’s on a line.

      Another useful remapping is changing Vim’s leader character to , from \. Just put this into your .vimrc:

      let mapleader = “,”

      The \ character is quite a reach on most keyboards, but the comma is easy to reach.

      At some point, if you continue using Vim, you will find your .vimrc becoming very large. Mine is several hundred lines long. You might find it useful to split it between several files, one for each type of setting or by some other organizing principle. The source command will pull in content from other files. This is how I have mine arranged:

      source $HOME/.vim/myconfig/options.vim
      source $HOME/.vim/myconfig/variables.vim
      source $HOME/.vim/myconfig/autocmds.vim
      source $HOME/.vim/myconfig/functions.vim
      source $HOME/.vim/myconfig/keymaps.vim
      source $HOME/.vim/myconfig/abbreviations.vim

      If you start using extensions to Vim, you may want to start with the pathogen plug-in. It makes it easy to install AND remove plug-ins. Otherwise, a plug-in’s files end up scattered around your .vim folder.

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

      You can browse this URL for more Python stuff related to Vim:

      http://www.google.com/cse?cx=partner-pub-3005259998294962%3Abvyni59kjr1&ie=ISO-8859-1&q=pathogen&sa=Search&siteurl=www.vim.org%2Fscripts%2Fscript.php%3Fscript_id%3D1905#gsc.tab=0&gsc.q=python

      I hope this stuff helps.

      :wq

      • asmeurer says:

        Wow. Thanks for all the tips.

        I installed the CamelCase plugin. For some reason, it maps ,w to move between CamelCase, instead of just remapping w (I guess it just wants to be cautious, but that’s useless, and we already have WORDs, so what’s the point?). But, once again, the vim language is easy enough to understand that it took me half a minute to fix it.

        I added your tab stuff to my .vimrc, and it seems to have fixed the problem.

        The completion is cool. I opened a SymPy file and started typing something and then CTRL-p, and it scanned *all* the SymPy files for completions. And then when I deleted some characters from the word, it remembered that I had completed it, and started searching again. Are there better keys to move around the completions than the arrow keys, though? I would look it up in the help, but I don’t know how to search the help for a CTRL command.

        I don’t get the point of the mapleader tip. From what I can tell from the docs, it changes the semantics of the map command. But this doesn’t seem to be something that I will be using all the time. Anyway, \ isn’t too hard to type on my keyboard (it’s right above RETURN). Maybe it’s *really* hard to type on your keyboard? Or am I just missing the point here?

        pathogen seems a bit excessive at this point, but I’ll definitely remember it if things start to get unwieldy.

        Thanks for the tip about the tagslist plugin. I’ve set \ to open that, as it that key is surprisingly unused, and I suspect I will be using it a lot.

        And once again, I found myself modifying the plugin to make it better. I added the Tlist_Nospell option, which lets you disable spell checking in the taglist (because I have set spell in my .vimrc, but don’t care about spelling in the taglist). If you are good a vim programming, you might check that I did it right. My change is at https://github.com/asmeurer/dotfiles/commit/dc5ac5b4f6ea922be6c050193e549bcc28cff37b. And if you think it’s good, I probably should submit it upstream…

    3. Scott says:

      control-n and control-p cycle through the next and previous matches in the list. You can read more about it by typing :help i_ctrl-p in Vim. That help file also has information about all commands you can use in insert mode, not just about the completion system.

      The leader character is used mostly by plug-ins to assign keys to commands, or by users to create custom mappings for commonly-used Vim commands. It is there mostly to prevent problems with plug-in authors and users remapping Vim built-in commands. For the same reason, user-created ex commands must start with an upper-case letter. Lower-case commands are reserved for internal Vim use. For example:

      nmap b :buffers:b

      This displays a list of open buffers and leaves you at a prompt for a buffer number to switch to when you type the leader character followed by b. By using instead of an explicit \ or , in the map command, the user can change the leader character without messing up custom mappings. Type :help leader in Vim to read more about it. Key maps are distinct from macros, which are used for on-the-fly automation. Macros are created with keystroke recording and stored in registers. They can be edited by pasting them into a buffer, editing like any other text and then yanking them back to the same register. You can read more about macros by typing :help q in Vim.

      I could go on and on, but that would spoil all your fun. Suffice to say that Vim can do whatever you need it to. It either already has what you want built-in or there is a plug-in that does it. Only Emacs can match it feature-for-feature. No other editors can compete with these two.

      :wq

      • asmeurer says:

        I’m not a fan of the way completion works. Perhaps it can be configured to be better. I would prefer something more like the readline completion from the command line. I start typing something, and it shows the completions. I start typing more, and it narrows it down, etc. If there is text after what I’ve typed that is common to all completions, it types that automatically.

        The control-p way doesn’t work like this because once I type control-p, it enters the first completion, making it impossible to type more to narrow it down.

        Another thing I’m not a fan of based on one of your suggestions: in visual block mode, you can’t select past the last character in whatever line the cursor is in, making it impossibile to select rectangular regions of text in many cases, unless you add sufficient whitespace to the end of the last or first line (depending on what direction you select in).

        Also, if I yank something from visual block mode, it’s repasted *over* lines (if that makes sense). I suppose this could be useful in some cases, but I often (usually) don’t want it. Any way to disable that?

        • Scott says:

          ” allow moving cursor beyond the end of the line
          set virtualedit=all

          That will fix the problem with visual block mode. Visual block mode is more for replacing text already in your file rather than for yanking, but it will yank exactly what is highlighted, no less. V will start line-wise visual mode, which selects by lines, and v will start character-wise visual mode.

          Or perhaps what you are looking for is behavior like in Windows, when you select text and type replacement text, what you type only appears once? In that case, what you want is select mode. You can start that by typing gh or gH and using the arrow keys, or use the mouse to start select mode and extend the highlight. It looks like visual mode, but behaves differently.

          For completion your way, what you want is the SuperTab continued extension: http://www.vim.org/scripts/script.php?script_id=1643

          From its vim.org page: “Supertab aims to provide tab completion to satisfy all your insert completion needs.” This version of it is a fork/extension of the original vim extension by another author. You can also supply your own functions to customize how it does completion.

          :wq

          • asmeurer says:

            virtualedit=block is what I wanted. Thanks.

            I don’t care about over typing text. I can just press c before I start typing if I want to do that.

            Supertab lets you use the tab key, which is cool (I’m not sure yet if I like it), but it doesn’t change the behavior of the completion, which is what annoys me. I want the completion to only actually text that is common to all completions, unless I specifically choose a particular completion to use.

            The way it works now, I have to know ahead of time what all the completions look like, so that I can type just the right amount of text to get it. Otherwise, by the time I C-p to the one I want, I could have just typed the name of the variable already.

            Also, these seem to suffer from a lack of caching. Every time I press tab (or C-p), it rescans the whole directory for new completions. It should just do this once, and remember it. The way it is now, it is too slow.

            I’m not blaming you for these problems by the way (unless you are the one who wrote the code). I’m just pointing out the deficiencies in the hopes that there are work-arounds. I also look forward to seeing how emacs handles all of this.

        • Rich Cheng says:

          Not 100% sure if I understand exactly how you want completion to work, but I think you’re looking for something along the lines of:

          :set completeopt=menu,longest,preview

          • asmeurer says:

            Well, as you’ve probably discovered by now, I’m actually using emacs as my main editor. But thanks for the tip anyway (hopefully others who come to this site will find it useful).

            That still doesn’t seem to do quite what I want, but it’s closer. I really like the behavior of the emacs extension auto-complete-mode (see the part 3 blog post).

    4. Scott says:

      I forgot that wordpress removes angle brackets. That nmap command should have the word leader surrounded by angle brackets just before b.

      :wq

    5. Scott says:

      I don’t know the specifics of how the completion system works, but apparently, it was implemented with a focus on flexibility, trading caching and maybe other features for flexibility in implementation. Also, it is mostly just the infrastructure of the completion system that is in Vim. In other words, actual completion for various languages is left up to plug-in authors to implement, along with any caching. Caching may be available in specific completion plug-ins for specific languages. However, there is a plug-in that may mitigate some of the problem. I haven’t tried it, and I don’t really know if it is directly about solving this problem, but here is the URL: http://www.vim.org/scripts/script.php?script_id=2620

      The page describing it is vague about its purpose, but the name seems to imply that it is about caching for the completion system.

      I suspect that Emacs has a more robust completion system built-in. It’s been around longer than Vim and it is a much more complete development environment. It is often accused of being a great operating system. If that is the case, it may work better for you. Personally, I haven’t been able to get my head around its Lisp extension language and don’t have the patience to tackle it.

      :wq

    6. […] I noted in part 1, I have decided to switch to a command line text editor. I decided that, to be fair, I would try […]

    7. Rich Cheng says:

      Pressing ‘l’ doesn’t bring you to the beginning of the next line because you don’t have ‘l’ in your setting for ‘whichwrap’.

      :set whichwrap+=h,l

      (but yes, if you find yourself using either ‘h’ or ‘l’ frequently, then you’re probably not getting the most out of Vim’s interface.)

    8. […] time using them to do true editing work. My experiences are chronicled in my blog posts (parts 1, 2, 3, and 7 months later follow […]

    9. […] reasoning. A couple of weeks ago, while not being able to fall asleep, I ended up reading about the differences between editors emacs and vim. I really like to get informed about something before usage, and in accordance to my projected use […]

    10. Just a second to enjoy your self with a good game in your own comfy home, and hopefully some winnings as well! Even when you aren’t a serious gamer you can’t deny that you don’t perform a sport sometimes.

    Leave a comment