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:

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


  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.


  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

" Add a newline after every semi-colon

" 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

" 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

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

" Go to the beginning of the file

" Record a macro to sort the attributes

" Repeat the macro a few times

" Indent the whole file

Edit: Fixed the backslashes. WordPress sucks.

Posted in vim