Poor man’s password manager

As a web developer, I often need to connect to our clients’ FTP sites to upload updates. Because I care about security (a little at least), I don’t want to keep passwords in a plain text file. I could’ve probably used one of the many password manager programs out there, but as a vim geek, I decided to go with a more low-level way.

Vim has a command, :X which will prompt for a key and encrypt the file when it’s written. When you open the file in Vim again, Vim will prompt you for the encryption key. If you get it, you’ll see the text, if you don’t, it’s all garbage.

There are some security concerns: when you’ve opened the file, the swap file is in clear text, so someone with read access to your swap files could get your password.

The slow downfall of Emacs?

For many, many years, vi derivatives and emacsen were the top 2 *nix editors. They owned pretty much everything except the occasional pico user. Today, I read this article where a majority of users still prefer vi editors. This isn’t unexpected, vi and vim are *always* #1 in all editor polls. What really surprises me is that both GEdit and Kate are more popular than Emacs. Why is that? Not pretty enough? Too powerful for the simple needs of the new users that Ubuntu brought to the Linux world?

My top 5 vim scripts

Linux.com has an article about five scripts that make life easy in Vim (for the author at least.) I skimmed it very rapidly to see what the author used, but none seemed too useful to me. This is why I decided to write my own top 5 list of vim scripts.

  1. BufExplorer1: For the longest time, I worked with Vim by editing one file, saving and exiting, editing another file, saving and exiting and so on. Working with Emacs, I learned to stay in the editor for extended periods of time and opening a lot of files. When I came back to Vim, I needed something to make it easy to edit a large number of files in one session. :ls and :b were passable, but I disliked the two-step operation to switch from one buffer to another. (Note: it was only after I installed BufExplorer that I learned you can Tab-complete buffer names.) The folks from #vim quickly pointed me to BufExplorer, and it’s excellent! You use \be (or in my case, ,be) to display the list of opened buffers in your current window (the list is the same as the output of :ls.) You go over the buffer you want to visit and press Enter and you’re there. It’s quick and easy. I’m so used to it, sometimes I write ,be in irssi.

    Some people use minibufexpl, I tried it, but it didn’t seem to play too well along with Project, so I uninstalled it

  2. Project2: One thing I always liked about IDEs and from the Textmate screencasts was the file list on the left of the screen. You can have that with Vim just by opening a directory, but you can sometimes lose the list and it’s annoying to bring it back. Listing the content of a folder also showed files you didn’t care about. Project.vim is a script that displays only the files you want in a vertical split window that always sticks around (even when you use C-w o.) You start a new project with the :Project foo command. Once that’s done, \C will ask you a few questions (name of the project, absolute path of the project, file filters) and the files and directories will be loaded in that buffer. You write it (:w) and next time you open vim, you do :Project foo and the file list comes back. I found this script to be extremely helpful in projects with a large number of files and directories.
  3. NERD_Comment3: I write code, and often I want to comment/uncomment large portions of code. I could do it manually, but it’s usually slow, especially in languages such as Python where the comment character comments only until the end of line. NERD_Comment gives you a handful of commands to comment and uncomment code with a simple command. The most basic way to use it, select code in visual mode, press \c<space> and the section will be commented. Select the same section again (use gv) and do the same command, and the code will be uncommented. This is not a big time saver, but it’s quite useful.
  4. Align4: Align is a plugin to align code according to a list of characters. Suppose you have the following code:
        firstname = 'Vincent'
        lastname = 'Foley'
        age = 23
        height = 170
        weight = 180
        blog_url = 'http://gnuvince.net'
        favorite_drink = 'beer'
        

    Personally, I don’t like code that’s unaligned like that, I find it hard to read (Damian Conway, the author of Perl Best Practices agrees with me on that point.) The solution is to align the equal signs, but that’s kind of a drag to do manually. The Align script automates this process; the command :Align = will align the visual selection on the = character. You can use the :AlignCtrl command (which has a lot of options) to set how many spaces to pad with, left align or right align, etc.

        firstname      = 'Vincent'
        lastname       = 'Foley'
        age            = 23
        height         = 170
        weight         = 180
        blog_url       = 'http://gnuvince.net'
        favorite_drink = 'beer'
        

    Small problem with Align however, in UTF-8, it does not deal well with accented characters. I contacted the author about this problem, but I haven’t seen an update so far.

  5. taglist5: When you are brought into a large project, it’s sometimes hard to learn quickly where things are defined and whatnot. A good way to help is to use taglist (given that ctags supports the language you’re using) which will list classes, methods, functions, variables and other elements of your language and make them easy to access. This makes it easy to jump from one usage of a function to its definition.

1: http://www.vim.org/scripts/script.php?script_id=42
2: http://www.vim.org/scripts/script.php?script_id=69
3: http://www.vim.org/scripts/script.php?script_id=1218
4: http://www.vim.org/scripts/script.php?script_id=294
5: http://www.vim.org/scripts/script.php?script_id=273

Vimperator update!

Vimperator has been updated! Version 0.3 is out, and two of the “complaints” I had have been fixed! Here’s the changelog:

17/04/2007:
* version 0.3
* added Ctrl-v support to pass one key to firefox (patch by Muthu Kannan)
* also ‘I’ will go to ‘ignorekeys’ mode until esc is pressed, presenting a workaround
for many javascript form fields like GMail, until something better comes along.

* Vimperator can now be automatically updated in the :addons screen like other extensions
* fixed :tabnext/:tabprevious commands
* documented ‘s’ and ‘b’ guioptions flag for statusbar/bookmark bar
* implemented the possibility to use CTRL-[ as an alternative to ESC, to leave the command line
* added Ctrl-Tab and Ctrl-Shift-Tab support for switching tabs without beeping
* ability to use shift and ctrl with special keys like F1 in mappings
* small documentation and other fixes

Emphasis added to the items that I had some issues with. Great job!

Vimperator: Vim-like navigation for Firefox

A few days ago, my friend jamessan mentionned on IRC a Firefox extension called Vimperator, an add-on that gives vim-like key bindings to Firefox. I didn’t try it at the time, but when the link was posted on programming.reddit, I decided to give it a try.

It’s an absolutely awesome extension, you use j and k to scroll down and up on a page, Ctrl-F and Ctrl-B are the equivalent of PageDown and PageUp, you can yank the current URL by pressing y and you can delete a tab with d.

The one feature that absolutely blew me away was the QuickHint mode. You press the letter f and all the links in the page have a small “tag” attached to them with a two letter code. Typing that letter code in lower case letters opens the link in the current tab, in upper case letter, the link is opened in a new tab. It’s an absolutely fantastic way to navigate without ever having to reach for the mouse.

As in Vim, you there is a command-line that is accessible by pressing :. The usual commands such as :q, :set, :bd, :h are all available with some more thrown in for browsing. One such command is :open (which you can also launch just by pressing o in command mode). :open gnuvince.net will navigate to this blog. :open gnuvince will perform a search on Google for ‘gnuvince’. :open imdb godfather will do a search on IMDb for ‘godfather’. The documentation doesn’t mention which search engines are supported, I know of Google, IMDb and Wikipedia so far.

Vimperator is not without flaws however. First, since the actions are done with single keys, you lose the ability to use them in applications such as Gmail or Google Reader. Using j and k to go to the next/previous message no longer works, you can’t archive messages by pressing the y key, etc. I’m quite used to those keys, so it’s kind of a drag to reach for the mouse in these cases. I think the problem could be fixed by having an equivalent of insert mode: pressing ‘i’ would make Vimperator ignore the keys (except for Esc to go back to command mode), thus allowing Gmail and other applications to work properly without Vimperator pre-emptively capturing those and performing their actions.

Speaking of keys, the key bindings for Back and Forward are H and L respectively. h and l are used for scrolling a page horizontally. Since it happens way more often that I want to go back than scrolling a page (which almost never happens anymore anyway), I think the bindings should be inverted.

Vimperator also replaces the default status bar with its own vim-like status bar. I have a Gmail pager add-on that displays the number of unread messages in the status bar, so when I use Vimperator, I lose that, so Vimperator effectively renders another add-on useless. Hopefully, future releases of Vimperator will make the status bar visible again. They should probably add that to the ‘guioptions’ setting.

For now, I have disabled Vimperator, but I’m keeping it installed because it’s so cool and I hope that future versions can fix the problems I mentioned.

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.

Reformatting a CSS file with Vim

Derek Slager wrote a post (and made a screencast) of how you would clean up an ugly CSS file. I decided to do it in Vim. Here are the steps. No screencast from me, unfortunately.

" Replace all sequences of white spaces with one space
:%s/[ \\t\\n]\\+/ /g

" Go to the end of the command, then forward one character and insert
" a newline
]/lr^M

" Add a newline after every semi-colon
:%s/;/;^M/g

" Add a newline after every opening brace and make put one space
" between it and the preceeding text
:%s/\\([^ ]*\\) *{/\\1 {^M/g

" Add two newlines after every closing brace
:%s/}/}^M^M/g

" Remove 'trailing' spaces in front of the semi-colons
:%s/ *;/;/g

" Make sure there is only one space after a colon
:%s/: */: /g

" Make the text before the colon lowercase
:%s/\\(.\\{-}\\):/\\L\\1:/g

" Remove all trailing spaces at the beginning of lines
:%s/^ \\+//g

" Go to the beginning of the file
gg

" Record a macro to sort the attributes
qa2jV}2k:sort^M}q

" Repeat the macro a few times
20@a

" Indent the whole file
gg=G

Edit: Fixed the backslashes. WordPress sucks.

Posted in vim

Emacs and Vim

I spent this week using Vim. Yes, me, the Emacs fan-boy using Vim. Why you ask? Because it was better than using Zend Studio. See, we are working on a PHP project at work, and the general slowness of Zend and its primitive key bindings left me wanting for more. I tried Emacs, but I ran into a few indentation problems. Also, I knew that I wouldn’t be writing as much new code as correcting mistakes in old code, so I thought that Vim would be the best for that job. And it was; I quickly got back into Vim mode in spite of not using it for much more than configuration files editing. This made me think about Vim and Emacs as editors and of course, which one is the better one? The short answer: neither is better than the other. They both got great features in common that other editors lack such as file recovery. There are some points however where I have a preference for one or the other. This is what this post is going to be about, a bunch of features where I think one of the two has a advantage.

Editing (Vim)

Vim is king when it comes to editing code. There is no contest whatsoever. Take any general- or specific-purpose text editor, pit it against Vim and Vim will come out as the winner. I like modal editing, it gives you a whole lot more commands to work around with your text. As you may have heard if you are no a vi/vim user, the commands such as deleting, changing (deleting and going back in insert mode) and yanking (copying) can be mixed with the very powerful movement commands. You want to delete text until the second closing parenthese? d2t). That’s it. The 2t) command brings the cursor over the character preceding the second parenthese after the current position of the cursor. To delete the text between these two positions, you just prepend ‘d’. Emacs doesn’t have this kind of power. You need to go in mark-mode (where you select text), and use either the movement commands or do a search on ‘)’, hit C-s to go to the next match and then C-w to kill the mark. This works, of course, but it’s a bit more work. Vim also does an operation on an entire line if you press on the operator key twice: dd deletes the current line. The way to do that in Emacs is C-a C-k C-k (or just one C-k if you set kill-whole-line to T). No matter what other modeless editors try to do, I don’t think they can match the editing power of Vim, period.

Edit: A helpful commenter mentioned the zap-to-char command, which is mapped to M-z, so my example that Emacs can’t delete up until a particular character doesn’t work anymore. However, if we change the operation from deleting to upcasing or downcasing up until a particular character, Vim works the exact same way (with the gU and gu commands.) Emacs doesn’t have such a built-in command, so you will need to select the text and then use M-x upcase-region.

Key bindings (Vim)

I love the Vim keybindings. The non-reliance on the modifier keys such as Ctrl and Alt is appreciated by my wrists. I don’t have carpal tunnel, however, after long Emacs editing sessions I sometimes feel a lot of pain in my wrists. Vim is also better when I use a french canadian keyboard. As an example, in Emacs to indent a region, the keyboard shortcut in C-M-\. On a US keyboard, this isn’t so bad, however on a french keyboard, writing a backslash is done by pressing AltCar (the Alt key to the right of your space bar) and the ` key as located on a US keyboard. This key sequence is so awkward that most of the time, I just use M-x indent-region instead. With Vim, I select the region with V (visual line) and press = to reindent. No pain there. Vim also just has a whole lot more keybindings than Emacs. In a column called My save-excursion, Steve Yegge, a die-hard Emacs user, writes a Lisp function to count the number of characters in the current buffer. He also counts word by simply dividing the number of characters by 5. Commenters are quick to point out that he could’ve selected the entire buffer and ran the wc Unix program on that selection (the complete sequence is C-x h M-| wc <RET>). Surprisingly, I don’t think I saw any Vim user say that he could’ve used g CTRL-G had he been using Vim. If you want to see some unusual Vim commands, look at all the g and z commands.

Selection mode (Vim)

In Vim, selecting text is called visual mode, in Emacs it’s setting the mark. I prefer Vim here too for the same reasons as editing. One of Vim’s visual mode is the visual block mode. It allows you to define a rectangle and edit on that section. Emacs has something similar, however you need to visualize the rectangle: the entire lines are selection (except the first and last) and you need to remember that when you are going to use a rectangle editing command (which are all different from the normal mark commands by the way, another source of annoyance) the section that’s going to be worked on is the wide as much as from the beginning of the mark up until the end of the mark. It’s kind of hard to explain, but Vim makes the whole thing easier by showing you just the rectangle you are about to edit. And in Vim, the keys do not change; d will delete the rectangle as it deletes a normal selection. In Emacs, deleting a normal selection is C-w, but deleting in rectangle mode is C-x r d. I often forget the rectangle editing commands in Emacs.

Syntax highlighting (Vim)

There’s only one word to win this for Vim: inkpot. Inkpot is the sexiest color scheme ever, it puts to shame all other vim and Emacs color schemes. Vim also seems to color more elements than Emacs, so that’s another point in its favor.

Hey, funny story, while I was looking for a screenshot of inkpot, Firefox froze up and for some reason froze openbox, my window manager, too. I hadn’t saved this post (which I am writing in Vim), but Vim’s recovery system worked flawlessly. I wasn’t even worried.

Auto indenting (Emacs)

Maybe it’s because Emacs has a more powerful and expressive extension language, but Emacs has less problems with auto indenting than Vim. Here are two examples:

# Emacs indenting Python code
foo(10,
    "hello")

# Vim indenting the same Python code
foo(10,
        "hello")

# Emacs indenting Ruby code
a = {
  'one' => a.sort { |a, b|
    a.length  b.length
  },
}

# Vim indenting the same Ruby code
a = {
  'one' => a.sort { |a, b|
    a.length  b.length
},
}

In pretty much any language I used, the Emacs indenting was always better than Vim’s. Emacs has also a command that I find myself using all the time called M-x align. Basically, you select a bunch of assignment lines, you call align and all the equal signs will be aligned. It also works with dictionaries/hashes. Aligning code makes it easier to read, and it’s nice that I don’t need to do that by myself.

Command line (Emacs)

When I talk about the command line, I refer to the minibuffer in Emacs (accessible with M-x) and when you do a :, / or ? in Vim. Emacs has a few advantages here. Although both do tab completion, Emacs’ minibuffer works with dabbrev-mode, so you can type the beginning of a word then M-/ and Emacs will complete the word. If there are multiple matches, pressing on M-/ again will cycle to the next match. Vim cannot do that, using CTRL-P and CTRL-N will go up and down the history of commands. Another thing I prefer about Emacs is that when you use C-x C-f to open a file, the current working directory appears, so you know exactly where you are; Vim doesn’t do that. The iswitchb-mode in Emacs shows all the buffer names when you press C-x b, and when you start typing, iswitchb will match that string anywhere in all buffer names and remove those that don’t match. This is a very powerful and very useful way of changing buffers. This makes it easier, in my opinion, to work with multiple files in Emacs.

Extension language (Emacs)

Emacs is configured in Lisp, Vim is configured in VimScript. Lisp is just more powerful than VimScript and it is also more present in the system: I can do C-h f to view the documentation on a Lisp function, I can do C-h v to view the documentation on a Lisp variable. I can use any buffer to input Lisp code and C-x C-e will evaluate it. When I was looking for a way to wrap text in rcirc, an IRC client for Emacs, at the width of the narrowest window, I needed to write a function to find the smallest width. Here’s that function:

(defun narrowest-window-width ()
    (apply #'min (mapcar #'window-width (windows-list))))

Easy, isn’t it? And I was able to find about window-list and window-width by using the afore-mentionned built-in help system for Lisp. When I look at the available modes and applications for Emacs, such as Gnus, ERC, rcirc, tetris, I can’t help but think that the Emacs folks chose the best possible language to extend Emacs. Vim supports many other languages besides VimScript, such as Python, Perl, Ruby, TCL, mzscheme, but I don’t think we’re likely to see popular extensions in those, because since they rely on a scripting extension that might not be available, portability is lost. Maybe a future version of Vim will officially support a second scripting language that will be included in the default distribution.

Documentation (tie)

Both editors have a tremendous amount of documentation that is browseable directly from the editor. I know I said earlier that I would list only the features where one editor had an advantage, but good documentation is often ignored in the open source world, and it’s important to mention that both editor are top-notch in this area.

Integration with other tools (Emacs)

Emacs has been integrated with virutally every tool in a programmer’s toolbox: debuggers, make, compilers, interpreters, manual pages, grep, version control systems, shells, you name it, there’s an Emacs mode to interact with that. The reason Vim gives to explain this lacking can be found in the *design-not* section of the documentation (:help design-not):

– Vim is not a shell or an Operating System. You will not be able to run a
shell inside Vim or use it to control a debugger. This should work the
other way around: Use Vim as a component from a shell or in an IDE.
A satirical way to say this: “Unlike Emacs, Vim does not attempt to include
everything but the kitchen sink, but some people say that you can clean one
with it. ;-)”

In spite of this goal, it appears that Vim users want more and more. The Clewn project integrates gdb with vim, Vim-Shell makes it possible to run shells and other programs in Vim’s split windows. Most languages have syntax and indent files, but people are now uploading plugins to http://vim.sf.net to make the manipulation of certain type of files (C files, Python files) easier. To an Emacs user, this sounds like they are trying to replicate the features found in Emacs’s programming modes. In version 7, new features have been added to VimScript (:h new-vim-script) such as lists, dictionaries and function references to make the extension language more powerful. A more powerful extension language means more advanced plugins. I expect that Vim will soon have programming support that rivals Emacs’ most powerful modes.

Folding (Vim)

Vim does folding out of the box, Emacs has something really basic called narrow-mode. Vim’s folding is much more like what we’ve come to expect from an editor that what Emacs offers. Vim also has the advantage of having multiple folding methods (manual, indent-based, marker-based, etc.) and has a bunch of z commands to open and close folds.

Self-contained (Vim)

Starting with version 7, Vim has its own built-in spell checker. This is a good thing, because you don’t have to rely on an external tool to do the spell checking. The *develop-spell* documentation section describes more technical reasons why a built-in spell checker was a better idea for Vim. Emacs integrates with existing spelling programs. On Unix systems, it’s not so bad to install ispell or aspell, but I’m not sure how easy it is to get them working on Windows systems. With Vim, I know I can have spell checking anywhere without having to install a separate, non-related package. Bonus points for the cute squiggly lines under the misspelled words. And as with anything in Vim, there is a flurry of commands to go to the next/previous misspelled word, add it to the dictionary, correct it, etc.

Version 7 also has a command called :vimgrep which works like :grep, but which doesn’t depend on an external grep command. This means that on Windows, where you are unlikely to have grep installed, you can still use that functionality. Again, Emacs’ M-x grep command relies on an externally installed grep program.

Having these commands built into the editor means that your workflow remains the same regardless of the platform you are working on. If you rely on external tools on one platform, then you move to another, your workflow is affected because the same commands cannot be used because the external programs they rely on are unavailable. A side effect of having more features built-in as opposed to being third-party additions is that pretty much everyone will use them, and bugs are much more likely to be found and fixed. It also reduces the number of files you need to carry around to have a comfortable environment. My elisp/ directory is 8 MB and I need it all to feel comfortable. With Vim, I just need my .vimrc file, the inkpot color scheme and the french spelling files. Beyond that, everything I need is already in Vim.

Completion (Vim)

In version 7, Vim introduced omni-completion, which is a bit like IntelliSense. Emacs has an external mode called CEDET that supposedly does something like that, but I was never able to install it, so I don’t know how well it works. OmniComplete is great however. If you type CTRL-P or CTRL-N and there is more than one match, a colorful menu is displayed in which you can select the appropriate completion. See this page for some screenshots of the C++ completion. Completion scripts for other languages are expected to be released, keep an eye out at http://www.vim.org for them.