I have always felt the pull of Vim. An inner acceptance that my journey to becoming a true conehead must pass through the ability to know and wield the beast.

It would seem laughable to me only 2–3 years ago that most of my working day would be centred around the command line. My text editor path over the years has been: Pagemill => Dreamweaver => Coda/Espresso => Sublime Text, with brief dalliances with the likes of BBEdit, PHPStorm, TextMate and other ‘one night stands’ I forget.

The final push for me giving Vim a whirl was this piece by Harry Roberts. It was the first time I had read something that got across to me the fact that Vim wasn’t just a shed load of keyboard shortcuts. Rather it was an expressive editor. That commands were actually ‘talking’ to the editor. E.g. diw for delete in word.

So, having used Vim for nothing more than writing git merge conflict messages I decided to spend the month of July using the editor exclusively.

This post is in note form and catalogues my day by day struggles and usage. Don’t expect coherence or conclusions as such, it’s merely stream of thought ramblings, as they occurred to me.

Before I started

During the weekend before, I spent some time researching Vim. Watching YouTube/Vimeo clips, ordering a book on the subject etc.

I learnt that all the config stuff to do with Vim is held in a .vimrc file. However, things like the font used are specified for the Terminal window. Therefore, if wanting to use Consolas or Source Code Pro in Vim (for example), it’s necessary to set those in iTerm/Terminal.

I have a cousin who is a expert Linux system admin. His advice echoed that of Harry’s article; start as vanilla as possible and add things only as you need them. I kind of listened.

Before I started using Vim as my editor there were some things I didn’t think I could get by without:

• A file browser of some sort
• Some kind of status bar
• A decent colour theme
• Syntax highlighting
• Some code completion

To facilitate plugins in Vim, the common advice was to use a package manager; much the same as the ubiquitous Package Manager from Sublime. Vundle looked like the simplest so I went with that.

Here are the initial plugins I added (or attempted to) via Vundle:

Plugin 'https://github.com/scrooloose/nerdtree'
Plugin 'https://github.com/ervandew/supertab'
Plugin 'https://github.com/bling/vim-airline'

June 29th

The first day using Vim was incredibly frustrating. A large portion of the day and my entire evening was spent just trying to get Vim ‘set up’ with the small number of plugins I wanted running. It is possible to run Sublime in Vim mode (Vintage mode) and for some this would be the safest option; play with Vim’s key bindings in a familiar environment with the safety net of a mouse and a text editor you know well should things get hairy.

That’s not the way I generally roll. I like to throw myself in the deep-end. There’s nothing in any way ‘good’ about my approach. Given a safer alternative approach, in some ways it is idiotic but I’m the sort of person that when there are cakes in the cupboard has to eat them. Ergo, if there’s a mouse to be used, I’ll use it.

Getting Vim set-up to ones liking is a brutal experience for a front-end dev. I’d say it was about 1.5–2X more difficult than setting up Sublime after coming from Coda. I dare say, most people used to a GUI based editor would give up quickly. There’s a significant investment in time/effort when editors like Sublime are sat in the apps folder asking “Was it something I said?”.

Key in me making it to day 2 was getting the Vim Solarized theme set up correctly. This step-by-step saved my sanity: http://blog.pangyanhan.com/posts/2013–12–13-vim-install-solarized-on-mac-os-x.html

I also found out about another plugin, CTRL+P. It gives similar CTRL+P powers that I am used to in Sublime.
I tried to get Emmet working but something is screwy. Will come back to that later.

1st July

The day started badly (again). I was still unable to set everything up as I wanted. However by the end of the day I was 90% there; happy enough to abandon fiddling with set-up and concentrate on actually using the editor. Within a few hours I already felt I was starting to come down the other side of the initial mountain (mainly getting my head around there being ‘modes’ in Vim; such as ‘Visual’, ‘Control’ and ‘Insert’). Some useful things I’ve discovered and I’m trying to remember:

In Control mode:

• yat – copies (‘yank’ in Vim terminology) the contents of the tag I’m in (useful for copying a block of HTML)
• p – pastes in the yanked lines
• dit delete in tag – deletes everything inside the tag (for emptying an HTML node)
• dd deletes the current line (and it’s handy that deleted stuff is automatically saved to the clipboard)
• A sticks me in insert mode at the end of the line
• } or { jumps to the next or previous empty line
• Shift+o puts a blank line above the cursor and places me into insert mode
• gg take me to the top of the file
• G takes me to the bottom

At this point I’m only really toggling between Command and Insert mode. Visual mode has been useful at odd times. As an example if I want to copy a HTML class from markup to create a selector in a Sass partial I click v to enter visual mode, then highlight the text, then press y to yank (copy). Then I can switch to my HTML file (see below), type G and then p to put (paste) the yanked text.

Quickly switching between buffers (files)

Turns out that open files are referred to as ‘Buffers’ in Vim (the text is held in a memory buffer and then written to file – what I’d normally think of as ‘save’). There are all sorts of buffers but all I need to know for now is that my ‘open files’ are in buffers. I needed a way to browse through them and CTRL+P is proving useful for this.

The CTRL+P Vim plugin is allowing me to get back to the normal speed I work at in Sublime. The trick for me to quickly switch between the files I’m working in is CTRL+P (to invoke the file browser) and then CTRL+B (to switch to searching only buffers).

1st July (evening)

Read on more and more blog posts/Stack Overflow posts that the pre-installed version of Vim on OS X isn’t great. I therefore went down the rabbit hole of trying to get a more recent version installed (7.4) from source. I’ve cut out a huge section here documenting the trials and tribulations I endured getting a new version of Vim installed. Instead I have condensed it down into a working ‘how-to install a custom Vim from source’ and written it up as a separate post: http://benfrain.com/compiling-custom-vim-source-os-x–10–9-mavericks/

July 2nd

It occurs to me that using Vim has actually solved a bit of friction in my workflow. My Terminal is always open as I work. I use it to run Grunt tasks, and push/pull and commit changes to Git. I’ve tried a few plugins in the past to bring Terminal into Sublime put they never satisfied my needs. With my editor (Vim) now in the Terminal/iTerm I just have two things to switch between: browser and Terminal.

Not long after starting the days work with Vim I hit the first snag; doing a git pull origin branch command. After inserting a message for the merge conflict, this was the error:

error: There was a problem with the editor 'vi'.

A quick Google led me to this post: http://tooky.co.uk/there-was-a-problem-with-the-editor-vi-git-on-mac-os-x/ and the resolution: run the following to tell Git the correct executable to use (I’ve amended it as I am using the new Vim):

git config --global core.editor /usr/local/bin/vim

Things I’ve added, things still missing

There is no image preview in Vim (Sublime just got this in ST3) which isn’t a massive deal but would be nice to have. I’ve also not got any linting running for scss and JS – something I really appreciate, especially the JS side of things. Autocomplete is also weird. I’m not even attempting to use that at present. When I press ‘tab’ to invoke autocomplete it is nothing like the tailored list I see in Sublime. I’m ignoring that for now.

Always show balancing tags

I wanted a way to show balancing tags in HTML so installed https://github.com/valloric/MatchTagAlways – pretty useful.

Commands that proved useful today

• bw wipes out the current buffer (if you opened a file by mistake)
• Added set wrap linebreak nolist into my .vimrc to get word wrapping that doesn’t a word in half.

Things I read

• http://computers.tutsplus.com/tutorials/vim-for-beginners–cms–21118

In the midst of trying to get a newer install of Vim installed (see above) real life intervened. I had things to ‘get out the door’ so, tail between my legs, I fired up Sublime and got something actually done. At this point, I didn’t like Vim much.

Later I read this great post on trying to use Vim for the first time and nod a lot. He’s right. I’m certainly finding that grappling Vim with no-one to show you the ropes is rough.

A win!

With the new version of Vim (7.4) installed I can use:

set breakindent

And Holy mother of God – it works! I now have sensible soft wrapping of lines in HTML.

Substitute syntax

I ended the day with a couple of positives; firstly search and replace (known as substitution in Vim) in a file. The pattern is this:

:%s/sausages/bacon/g

The %s tells Vim to search and then the find and replace terms (separated by a /) followed by /g (meaning all instances rather than just the first). That example replaces ‘sausages’ with ‘bacon’.

You can also search and replace in a visual selection. Suppose you want to change the tags in a selection of HTML from a span to a b. First with the cursor anywhere on the wrapping tag type vat (select Visually Around Tag) and then:

:/s/span/b/g

Copying to and from system clipboard

One more useful thing I figured out; if I set set clipboard=unnamed in my .vimrc file then yank’s go into my system clipboard. More about this on this Vimcast episode although I need to re-watch a few times for all the different register commands to sink in.

Copying and pasting in and out of Vim is still fraught for me at present. I don’t have this sorted in my mind yet enough to get predictable results. Sometimes text comes in as I would expect, other times it horribly barfed.

Proper scss syntax highlighting

Finally I got a proper scss syntax installed (via Vundle): https://github.com/cakebaker/scss-syntax.vim so Sass files highlight correctly.

2nd July (evening)

Found a useful function on Stack Overflow to make a file and then also found a simple ‘how-to’ on using NERDTree to create files and folders (can’t find the url now – grrr). See also this tutorial on it:

http://code.tutsplus.com/tutorials/vim-essential-plugin-nerdtree–net–19692

Had 30 minutes to watch a few more of Derek Wyatt’s Vim Screencasts. I need to practice using [[ to jump to braces. * to jump to the next occurrence of the word the cursor is on and % to jump from brace to brace inside a function or declaration.

I also found out (or remembered) that I can use a to start in insert mode after the cursor. Useful as I still can’t wrap my head around Vim starting me under the cursor (as happens when using i to enter Insert mode).

3rd July

Noticed that I’m seeing *.html.swp files being added when I commit to Git. Turns out these are backup files that Vim creates in case of a crash. These should probably be added to the .gitignore file but it turns out that you can also alter where these files are kept.

Change where Vim saves swp files

I made a folder in my user root called ‘Vim-SWP-files’ and added this to my .vimrc:

set backupdir=~/Vim-SWP-files

Note: even despite this I keep seeing these files being committed so I added .swp files to the .gitignore (felt like defeat).

Make Vim display changed files immediately

Also, I noticed that when I have files open and bring in merges from my Git origin I get a warning about the file changing. Vim, unlike Sublime, doesn’t automatically read in the amended file. However, you can make it do so by setting:

set autoread

Highlight searches

I like having the search term highlighted when searching so discovered there’s a setting for this (there’s settings for everything with Vim it seems):

set hlsearch

That just goes in the .vimrc.

Editing

Things are starting to settle in a bit now. I find I’m automatically doing Shift+o to add a blank line in edit mode below the current line and Shift+O to add a blank line in edit mode above. Switching modes between Control, Insert and Visual is almost second nature already. I’m still having to consciously think about w and W and b and B to move between words though but using f to jump to any character in a line is hugely powerful.

Making use of Marks

I’ve also found out about ‘marks’. In principle this sounds pretty epic. You can make your place in a file with m and then a letter. So for example ma (whilst in Control mode). Go elsewhere on the page or another buffer and then quickly jump back with `a (the backtick goes back to that line) or 'a (the apostrophe goes back to the exact column number). If I can make sure I use this, there is a chance it will come in handy for yanking things (remember ‘yank’ is Vim speak for copy) from one file and putting them in another.

There are also a bunch of automatic marks:

• `. jump to position where last change occurred in current buffer
• `" jump to position where last exited current buffer
• `0 jump to position in last file edited (when exited Vim)
• `1 like 0 but the previous file (also 2 etc)
• ’’ jump back (to line in current buffer where jumped from)
• `` jump back (to position in current buffer where jumped from)
• `[ or `] jump to beginning/end of previously changed or yanked text
• `< or `> jump to beginning/end of last visual selection

End of day

The most positive part of today has been that I’ve not needed to open (or think about opening) Sublime Text. There are still things that niggle me about Vim (easily indenting HTML is a bit off, even when using gg=G which should go to the top of the file and re-indent to the end) but there are things that I’m really appreciating:

• easy jumping up/down braces with Shift { and Shift }
• * on a word automatically searches for that word so you can press n or Shift + n to skip through
• dat to delete a tag and all its contents
• dit to delete inside the tag
• >> and << indents the current line in either direction whilst still in Control mode

I still don’t have Emmet running and the autocomplete is nothing like Sublime’s at present but I’m happy to be feeling somewhat productive at this point with Vim.

July 4th

It may be independence day for Americans but for me, I’m not quite ready to go it alone with Vim. Thankfully, my copy of Practical Vim arrived in the post this morning so I’m looking forward to picking up more skills from digging into that.

In the meantime, today I have found the ^ symbol is great in CSS/Sass as it jumps to first non-whitespace character in a line after a curly brace (much like CTRL+ left cursor in Sublime).

Here are some things I still haven’t addressed with my first week with Vim:

• Defining a project (Sublime Text 3’s project switcher is amazing) and having some means of easily opening it/switching to it.
• Project wide search and replace. I’ve read some madness about how to achieve that with some text string lunacy but I’m not ready to accept (or understand) that as the only solution yet.
• There’s no ‘jump to definition’ feature (CTRL+R in Sublime). I’ve read about ctags but having to install a separate program and configure it to keep an index of definitions up to date is a no-go as far as I am concerned.

Week 1 round up

I end my first week using Vim feeling conflicted. I can see the immense power it affords but I also appreciate how little I know and understand this tool. I don’t think it’s a stretch to say that with Vim, more than any other text editor I have used, you can effectively build your own text editor. The core capabilities are shared but so much can be customised.

The ability to switch modes offers incredible speed but at the same time, I’m tripping myself up constantly at present. I’m often entering Insert mode inadvertently, putting text where it shouldn’t be and yanking text inaccurately.

For every new incredible capability with Vim I’m reading about, I have to consider that there are costs. I’m not sure how much of a burden the absence of a sane project wide find and replace (as one example) are going to be. This post has a great summary of Vim shortcomings which do worry me.

However, having started reading ‘Practical Vim’ I’ve already read enough craziness in there to make me think that persevering will prove a worthwhile investment of time.

Certainly I can see enough economies in the core text editing capabilities that I believe, even given the current pain points, I’ll ultimately be able to write and edit code faster with Vim than I could with something else.

Time will tell.