Code Kills

Vim functions to change tab treatment

2012-01-22T21:00:00Z

I've gotten tired of doing the :setlocal tabstop=... dance every time I start editing a file from someone who has their own unique feelings about how wide tabs should be... So I've written two little functions which make it easy to change a buffer's tab mode:

For example, when I start editing something written by someone who believes spaces are evil and tabs should be five spaces wide, I just need to :call HardTabs(5).

You and Your Editor: Vim normal mode commands g, : and d (3 of N)

2009-12-06T01:22:00Z

In my last post, I showed off some normal-mode data from vim-logging. In this (and the next few) posts, I'll go though my most-used commands and describe how I use them.

(Don't use Vim? This post won't be too interesting… Although you may pick up something useful)

g

My logs contain more than 60,000 references to the 'g' command (eight times more than ':', the next most frequently used command). This may seem surprising at first, but stick with me and let me explain: the 'g' command is something of a 'gateway' command - a prefix for a number of common actions which don't have their own single-character command (for example, gd, goto definition and g?, rot13 encode).

Here is a breakdown of the 'g' suffixes I often use:

gj and gk: cursor to next row, cursor to previous row ("make j and k do the right thing"). The j and k commands are defined as "move to next line" and "move to previous line", not "move to next screen row" and "move to previous screen row". This is an important distinction to make when long lines are wrapped, and I find "move to next/previous screen row" is a more reasonable default. Protip: use noremap j gj and noremap k gk in your vimrc.
gg: cursor to top of file. After using gg (for example, to edit some import statements or add a shebang line), I often use '' (tick-tick) to jump back to the line I was editing at the time (for example, ggofrom foo import bar<esc>''). Also, I often use ggVG (go to top, enter line-visual-mode, go to bottom) to select the entire file. From there, I can pipe it to something (for example, :!sort), format it (gw) or copy it to the clipboard.
gt and gT: go tab - move to next/previous tab.
gf: goto file - edit the file under the cursor. For example, if the cursor is over the 'e' in import "../eventDispatercherImpl.as", the equivalent of :e ../eventDispatercherImpl.as will be executed.
gw: go wrap. Wrap the selected text (that is, text selected in visual mode). Try selecting a long line (pressing V), then using gw to wrap it.

That's all the 'g' commands I can think of for now... The next version of vim-logging will log the sub-command used, so I will be able to provide better data in the future.

:

The colon command is fairly obvious: enter command-line mode to run commands like :w or :help :.

I'll write more about this later, when I analyze my most-used ex commands.

d

Ah, d - delete - the programmers best friend.

As with g, I do not have detailed information about how I use d, but I'll list the first few combinations that come to mind when I move my left index finger over the d key:

dd to delete whole lines
di( to delete everything inside a pair of parenthesise
dfx to delete everything between the current position and the next occurrence of 'x'
dj and dk to delete this and the next/previous line
d$ to delete from the current position to the end of the line
d in visual mode to delete the selected text.

You and Your Editor: Data from vim-logging (2 of N)

2009-12-06T00:19:00Z

Remember when I blogged about vim-logging? Well, I've finally gotten around to interpreting the results.

First, I will cover what I believe to be the most important thing to know about vim: the normal mode commands.

Below is a chart of my 39 (why 39? I can't remember - when I created the graph, that's the number I chose) most-frequently-used normal-mode commands:

(many - see discussion)	g
(ex mode command)	:
(delete)	d
(find in line)	f
(move forward word)	w
(insert mode at beginning of line)	I
(change)	c
(move to beginning of line)	^
(insert mode at end of line)	A
(move back word)	b
(undo)	u
(move to next search match)	n
(search)	/
(move left)	h
(z[nm]): close/open folds, z[tbz]: scroll window)	z
(insert mode before character)	i
(move to end of line)	$
(c_w-c_[wljh_] - window commands)	Ctrl_W
(insert mode after character)	a
(find backwards in line)	F
(insert node in next line)	o
(move cursor half screen down)	Ctrl_D
(move line down)	j
(move line up)	k
(enter normal mode)	ESC
(repeat previous find in line)	;
(substitute character)	s
(delete character)	x
(put from register)	p
(delete line)	D
(}} - move to next blank line)	}
({{ - move to previous blank line)	{
(enter visual-line-mode)	V
(go to bottom of file)	G
(replace)	r
(visual mode)	v
(yank text)	y
(change line)	C
(insert mode on previous line)	O

vim-logging: taking the superstition out of "most used command"

2009-10-17T19:33:00Z

After writing the last entry, You and Your Editor, I got wondering… What commands do I really use most often?

A few hours of hacking (and a bit of help from Blake Winton) later, I'd like to present: vim-logging.

If you're interested in trying it, the wiki page has all the information you'll need to get started.

You can expect a blog post in a week or two, detailing what I've discovered.

You and Your Editor: The Bare Minimum You Should Be Doing (1 of N)

2009-10-15T04:26:00Z

It's come up a few times, so I'll just go and post it here: the things, in no particular order, I believe to be the bare minimum you should be able to do while you're editing source code (and how to do them in Vim):

Easily move between files

All but the simplest scripts require more than one file, so you'll often need to switch between them.

Eclipse has two very useful features here: Quick Access (command+3) and Open Resource (command+shift+r):

And in Vim, I make heavy use of multiple windows (:new and :vnew, using custom shortcuts, c-h, c-j, c-k and c-l to move between them) and multiple buffers, using :b. For example, below, I have typed :b url<tab>, then I use c-p and c-n to cycle through the list of matching buffers (I also have <right> and <left> bound to :bn and :bp, making it easy to flip through buffers if I'm not sure what I want).

Jump-to-definition

When you're working with a large project, especially one for which you aren't the only author, it can become nontrivial to figure out where things (classes, functions, etc) are defined. I've found that it's very hard to read source code without a jump-to-definition function because it forces a mental context switch from "figuring out what this code does" to "figuring out where this method is defined", then once I've found where it's defined, "ok, now what was I looking for again?", and once I've finished reading the definition "why am I looking here again?" and finally to "what was the point of this sentence?"

With Vim, I use exuberant ctags to do this.

First, I run ctags -R . to build a tags file, then I access it using :tag, c-] and c-w ] from within Vim. Also useful is c-t: after c-] is used to examine a definition, c-t will take you back to the place you had originally found that definition. Very, very useful.

(note, for this to work properly, make sure :set tags=tags;/ is set in Vim)

Search for/highlight the current word

Often, when I'm reading code, I'll want to quickly look through all the references to some word in the current file (for example, to see where a variable is referenced or how a function is called). This sounds trivial, but I find myself doing it often. Very often. So give it a try before immediately disregarding it.

I do this in Vim using * and # and :set hlsearch (as a side note, I've also got \\ bound to :set nohlsearch).

For example, if my cursor is over load_BufferedImage, then I hit *, I can quickly jump through all the tests which call it.

That's all… For now

That's all for now, but stay tuned – I do love editing text, so I'll probably come back and write some more on this later.

PS: Just to make very sure it's clear, the only editors I mean to bash here are the ones which make it very hard to do the things I've talked about (nano, notepad, etc)… Every decent editor can do these things, you've just got to learn how.

PPS: If you don't already use it, Vim has a great built-in help system. Access it with :help {subject}. For example, :help vnew or :help <c-w>.

PPPS: Todd has posted a followup, Worthwhile vim tips – they are a bit more basic, but even more important than the things I've talked about here.

DrProject/Trac Wiki Syntax Highlighting for Vim

2007-08-16T14:39:00Z

After being frustrated with boring white-on-almost-black (spectro) while working with DrProject wiki files, I broke down and wrote a Vim plugin to make the syntax pretty. It will also parse most of the Trac syntax (and more should be easy to add).

Get it: http://wolever.net/~wolever/drpwiki.vim

Using it:

Save it to ~/.vim/syntax/drpwiki.vim (create the directory if it doesn't exist)
In Vim, enter `:set filetype=drpwiki`

Fixing Files with Vim Macros

2007-06-16T02:51:00Z

I got an email a couple days ago asking me to add a small header to all the pages of a website I work on from time to time. The site was built with static HTML a couple of years ago and this was the first site-wide modification I've had to make since then. So I fired up Vim, loaded the session I use to work on the page and got to work. It didn't take too long to make the changes to one page -- add a couple of JavaScript functions, add a call to the the body's onLoad property and finally a little div just below that.

But then came the problem. How do I apply this change to all the pages? Normally, to do multi-file search-and-replace, I use perl -pi -e 's/search/replace/g' `find . -name '*.html'`... But, in this case, I would have to run that three times (one for each block of text)... And more importantly I want to see the file before I edit it (because some of the HTML files don't use the standard template, so they would get horribly mangled).¹

So how did I do it? By writing a Vim script! I used gvim *.html to open up all the HTML files, them qa to record all my keystrokes in to register a.

As I made the changes, I used general steps so that they could be repeated on each file. For instance, I used /onLoad to search for the onLoad property of the body, then f=la to find the =, move one character to the right then insert my text. When that was done, I opened up the line right below the body tag with o and put in the div tag that I needed.

Finally, after saving the file, I used :bn to move to the next buffer and hit q to stop the recording. I could now look at the new file to see if it needed to be changed, then change it with @a or move on to the next buffer with :bn.

Now, this makes me curious... Faced with a similar situation, how would you solve a problem like this?

1: Now, in retrospect, I realize I could have used:

for FILE in `find . -name '*.html'`; do
  read -p "Edit $FILE? " R
  if [[ $R == "y" ]]; then
     perl -pi -e 's/old/new' $FILE
  fi
done

But that would assume that I was putting some serious level of thought in to this. Also, unless I also had the presence of mind to add cp $FILE{,.backup} I would not have any way to un-do my changes.