Five things I hate about Emacs and Vim

About a month ago, brian d foy wrote a post on his journal called What do you hate most about your language? and asked people who advocated a certain programming language to name five aspects that they disliked about their pet language. A few people such as Jacob Kaplan-Moss of Django fame answered.

Though they’re not languages, my advocating them compels me to write five things I hate about Emacs and five things I hate about Vim.

Emacs

  1. The key bindings: I can understand why some people don’t like modal editing, but Emacs’ key bindings suck. The editing commands such as deleting and copying aren’t done like in vi where you specify the text that should be affected with a movement command. Instead, there is a separate key chord for every action. Moving forward one paragraph is done with M-}. How do you kill to the end of that paragraph? With M-x kill-paragraph. There is no key set for that. However, you can mark an entire paragraph with M-h. You move forward one sentence with M-e, you kill to the end of the sentence with M-k, but there is no shortcut to select to the end of the sentence, you need to use M-x mark-end-of-sentence for that. It’s not regular like in vi. If the key chord M-d was a prefix to a kill command and that you could use a second key to describe the motion, that could be nice. M-d ) could kill to the end of a sentence, M-d } would kill to the end of the paragraph and M-d > would kill until the end of file. It would be a better way in my opinion, the knowledge you have on how to delete text would be directly transferable to copying text with M-w. It would also leave more key bindings available for other operations.
  2. Reliance on external tools: Emacs does spell checking by calling an external tool, usually ispell or aspell. On UNIX systems, you have a good chance that they’ll be installed by default, but no such luck on Windows. That means you need to download an extra program to work with Emacs. On the other hand, starting with version 7, Vim has a built-in spell checker that works on all platforms. Similarly, M-x grep depends on an externally installed grep command. On *nix systems, this is not a problem, but on Windows, this is not something available by default. Therefore, it would be nice if the grep command could also have its own built-in system that you can fall back onto if there’s no external grep command. I use :vimgrep very frequently on Windows, and I would love to have the same work flow when I work with Emacs.
  3. No line numbers: Emacs doesn’t do line numbers like :set nu under vi. I really like having the line numbers on the left, and it’s something Emacs doesn’t do. There are some third-party solutions, but they all have major flaws: some actually insert and delete line numbers with a command, others are reportedly too slow. I tried setnu+.el, but it has some annoyance: the color of the number is the same as the first character. You would think that a task that is so basic that even vanilla vi had it would be supported out of the box by the “thermonuclear word processor”.
  4. The infinite configurability: I really love the fact that everything in Emacs can be modified; that’s how the editor became so powerful and also how everyone can adapt Emacs to his/her particular needs. My .emacs file is about 330 lines long, and my elisp directory is 8 MB. I really made Emacs behave exactly like I want it to. The problem with that however is that I am uncomfortable without my Emacs configurations. I have changed a lot of key bindings — some have been changed for so long that I don’t even remember that they’re custom — I have installed many third-party modes, I have a whole bunch of setq’s in my .emacs to configure all the options I care about to be exactly how I want them. If I lost my .emacs and/or my elisp directory, I would be in a lot of trouble; it took me years to find all the settings I cared about (so far) and to create my own little functions, I don’t know if I would go through it all again. In fact, this is how Tim O’Reilly switched to vi, he lost his Emacs configuration. I have it under version control, but it’s still a concern I have. I must confess that I have also a considerable .vimrc, however I require only a few configurations to be comfortable (incremental search, syntax highlighting and autoindenting), so losing my Vim configurations wouldn’t be as bad.
  5. Support for multiple modes in one buffer: I work as a web programmer, and as such, I often deal with files that mix HTML, Javascript, CSS and PHP code or Django templates. The Vim syntax files for PHP and Django handle all four syntaxes flawlessly. Emacs needs to use a special mode called mmm-mode to support multiple modes at once, and it’s really a pain to use. On the RubyOnRails page on Emacswiki, they show how to configure Emacs to deal with ERb files. The block is nearly 20 lines long. That’s a lot of configuration for something that some editors support out of the box. When I asked in the #emacs IRC channel, nobody could tell me what the at-signs (@) were for. For PHP, the page on HtmlModeDeluxe has an equally scary configuration block. In my opinion, HTML is so popular and ubiquitous that a mode supporting HTML, Javascript and CSS should be included in the default distribution. Adding Django or Rails or PHP support to that base HTML mode should be easy as well.

Vim

  1. Just an editor: Vim is just a text editor. It has some integration with external tools such as make or grep, but it is well mentioned in the documentation (:he design-not) that Vim is not Emacs and that you can’t run a shell inside Vim or use it to control a debugger or a REPL and that it is not one of its goals. I can appreciate that Vim follows the UNIX philosophy of being good at one task (i.e.: editing text), but it’s often useful when the editor does more for you than just text editing. I bought the PDF book for Erlang from the Pragmatic Programmers Friday; I started reading the first chapter, and I wrote the code in Vim, so I had to edit the code, save it, switch to the REPL and write c(module) to load my changes. When I got home, I tried Emacs with the Erlang major mode. I had my module open in one split window and the REPL running in another, and with a simple key chord (C-c C-k), Emacs automatically compiles the code in the REPL. The work flow with Emacs was much faster and pleasant. All languages that have a REPL and that have a decent Emacs mode have this ability (e.g.: Ruby, Python, O’Caml, Common Lisp, Haskell, etc.) There are other modes available for Emacs that keep your work flow going such as calendar-mode or calc-mode. If you need to check dates, set appointments or do some calculations, as a Vim user you will need to use another tool, because it’s not what Vim does.
  2. Vimscript: Vimscript is the extension language of Vim. It is not as tightly integrated as Emacs Lisp is into Emacs. In fact, you could say that Emacs the editor is actually just a Lisp interpreter. All the keys you press on your keyboard in Emacs map to a Lisp function. Doing C-b is the same as doing M-x backward-char. That’s not how Vim works however, there is a distinct separation, there is no colon command that you can call that will do the same thing as pressing b to go backward one word. So if you remap what b does and don’t provide a replacement, you effectively lose the ability to go backward one word at a time.. Before version 7, Vimscript was also missing some features that I like and use frequently when I code: dictionaries (hash tables) and funcrefs (higher-order functions.) Because you can evaluate a Lisp expression in any buffer in Emacs, I am more likely to write a small throw-away function to accomplish a certain task when macros aren’t up to the task. Finally, and this is completely subjective, I prefer Lisp over Vimscript.

  3. The command line: The Vim command line has completely different key bindings from regular Vim. In Vim, you have normal and insert modes, in the command-line, you’re always in insert mode. You use Emacs-like key bindings to move around the command line such as C-b to go to the beginning of the line, C-e to go to the end of the line, C-n to go to the next history command, C-p to go to the previous history command, etc. C-n and C-p normally do completion in insert mode, but their meaning is changed in the command line, so you cannot have completion there. When you want to switch buffers in Emacs, if you use iswitchb-mode, you see the list of buffers in your command line, and as you begin typing characters, Emacs removes the buffers that don’t match the string as you’re writing. It’s extremely useful. Under Vim, if you want to change buffers, you must use :ls to view the opened buffers, and then you can do :b {string} to switch. You can use Tab to complete, and it’ll look anywhere in the buffers’ names, however you don’t get the auto-updating list like in Emacs. I could list more examples where in my opinion the Emacs command line is better, but I’ll stop here for now.
  4. Split windows: If Vim is split in two windows, and you delete one of these buffers by using the :bd command, Vim will close that window as well. I would prefer if operations on buffers affected only buffers, not windows. When you use :q to close a window, the buffer this window was a view port to isn’t deleted, so why should the opposite be? My friend jamessan wrote a small function to deal with this problem, but there are caveats: it only deals with buffer deletion, not wiping them for instance. I’d like to see this problem be fixed properly. An option should be available to control whether the user wants buffer commands to modify his windows, something like :set keepwindows=1 would work.
  5. No wiki: Emacs has EmacsWiki, an awesome place where you can find a ton of information about all things related to Emacs. Pretty much every major and minor mode has its own page (some modes have more to organize the documentation by topic) where users can ask questions, post tips and tricks, etc. EmacsWiki is the first place I go to when I have a problem/question regarding a mode, a function, a variable, etc. You can find pretty much anything there. Vim currently doesn’t have such a spot. The official site has scripts (syntax files, indent files, plugins) that you can download, but these don’t have comments, so if you have an issue with a particular package, you can’t see if anyone ever struggled with the same problem. Tips have comments, but there hasn’t been a new tip in over a month, I’m not sure why. I think that a quality Wiki where people could share knowledge would be awesome.
About these ads

17 thoughts on “Five things I hate about Emacs and Vim

  1. You’re onto something with this M-d/M-k rebinding stuff – realizing I use M-d so often but M-k so infrequently, I kept M-d as it is, but turned M-k into a prefix command. Now M-k . kills to the end of the sentence, M-k } to the end of the paragraph, and M-k > to the end of the buffer. It feels pretty good so far…

  2. Regarding VIM point 3, just hit ^f at the colon command line. voila! editable history and command line using full VIM goodness.

  3. What I hate about Emacs on Windows: it doesn’t do Cleartype! Looking at characters with visible disconnected dots drives me up the wall. The Emacs people say it’s because Microsoft doesn’t fully document the spec, so there was no way to do it without problems. Yet somehow Vim seems to manage it. Why can’t they just go look at the Vim code?

  4. I think your rant about emacs kill commands not being symmetric to movement commands misses the fact that you can do what you want. If you prefix your command with M-@ (instead of your suggestion of M-d), then you can use *any* movement command to kill as you like. You just have to remember to finish the kill with C-w. This can be a bit tedious for short commands, but luckily emacs provies, as you suggest, shotcuts like C-k and M-d for many of them.

  5. Check out jedit or eclipse. Welcome to the nineties and graphical user interfaces.
    vi/emacs advocacy is purely a religious/political phenomenon.

  6. asdf: actually, the fact that jEdit and Eclipse only have graphical interfaces is an instant turn off for me. I edit a lot of files in putty over a SSH link, and being able to use the same editor there than on my Windows desktop is a definite advantage. Another thing, I don’t know about jEdit, but Eclipse doesn’t have macros. How the hell am I supposed to do anything without those? :)

  7. I guess you don’t know that jEdit has (as a plugin) something very much like Emacs’ tramp.

    Although I’m an Emacs-breathing, Python-charming, Unix-troubleshooting dude, no need to diss jEdit off the cuff, mate.

  8. line-number-mode comes with emacs out of the box. Add (line-number-mode 1) to your .emacs. column-number-mode also comes with emacs out of the box.

  9. Regarding jEdit & Eclipse… I’ve tried to use them both numerous times and can’t understand how anyone can be productive with those tools. I have a beefy machine (2 gb ram, p4 dual-core, etc) running Linux, and loading a project in either of those tools brings my machine to its knees. I also can’t seem to use either for more than 30 – 40 minutes without some sort of glitch or crash. Additionally, both are heavily geared towards Java development (which I don’t do thankfully), and implementing support for other languages feels clunky and bolted on (because it is). Maybe it’s different for the windows world, but from where I’m standing both Eclipse & jEdit aren’t viable options.

  10. @Luis Bruno: what I meant by SSH is that I actually connect with putty and then start either Emacs or Vim.

    @Michael Wolf: I have those, but they display the current line and column in the modeline. What :set nu does in vi/Vim is display those numbers at the far left of every line. I saw a post on M-x emacs-something blog about a better mode that setnu.el, I’ll have to check it out. Apparently, it’s fast even with large files.

  11. @Michael Barlow

    You can improve Eclipse’s performance under Linux when you run it with the JRE 6. It was the final argument for me to switch to Linux with my desktop pc when I heard about this trick an verified that it is true. Without Java 6 Eclipse sucks under Linux even on high powered machines.
    On my MacBook I prefer Textmate for Ruby development but I still count on Eclipse for Java development.

  12. Vince: I got it the first time around; I just wanted to point out that if your current method is incapable of taking advantage of graphics, it’s not the graphics fault.

    I changed from SSH’ing-and-Emacs-ing to Emacs-ing-and-SSH’ing-underneath because I couldn’t stand the lag sometimes (the research network linking .pt universities peers with the ISPs in Lisbon; my one-character-at-a-time traffic goes 600+ km for a jump of 1.2 Km).

    Editing root-owned files becomes a bitch, though; I usually “sudo vim” those. Emacs’ tramp can SSH-and-sudo, but it becomes an interesting.cn experience. And sometimes you need to reload a service or some such; there I go back to Terminal.app to fire up ssh.

Comments are closed.