Vimgolf workflow

Playing Vimgolf is different from using Vim normally to edit text. You can spend hours finding an impractical way to save a single stroke on a basic task. Vimgolf is 100% planning and 0% execution. There are no typos. If you're entering your solution and you mess up, you start over and get it right. Finding the perfect solution is difficult and rewarding.

Planning a solution involves a different workflow than regular text editing. If you start the vimgolf client, type the first thing that comes to mind, and call it good, you'll get terrible scores. My workflow honestly isn't that good, but when I talk to other players about theirs, my reaction is usually, "You do WHAT?!". So maybe I have something to share.

Take notes

When I start up the vimgolf client, unless the challenge is really easy, I open up a separate Vim to take notes in. It has to be a separate Vim. I ZQ to reset my vimgolf Vim all the time, and taking notes there would count as strokes.

The only really essential setting in my notes Vim is set ruler. I write solutions down in my notes, one per line, and the ruler tells me the stroke count. I insert control characters literally, using i^V. For instance, if I use Escape in my solution, I'd type ^V^[ to get a literal escape character. That's one byte, and the ruler counts it as such. You do not want to type <Esc> like you see on vimgolf.com. This confuses the ruler.

If my solution has a non-ascii keystroke, I write it as a control character. It's not a control character, but as long as I know what's going on it's fine. The important thing is not to confuse the ruler. For instance, if I want <S-Tab>, I write ^S.

The ruler reports cursor position: line number, bytes so far in the line, and column. The byte number and column tend to be different, because control characters are shown on screen with two cells. It's the byte number you want. A shorter solution can appear longer visually if it has more control characters. To compare solutions, $ to the end of the line and k and j up and down, looking at the byte number.

I like to see my notes and the vimgolf client at the same time. I keep my notes in a gvim window separate from the terminal that's running vimgolf. I've tried keeping them in the same terminal in a separate screen/tmux pane. It's better than nothing, but not as good. A split terminal with screen or tmux should be fine, but it's easier just to open a gvim.

When I'm done with a session, I throw away my notes. I use them to help me think, not to help me remember. In a couple minutes I could write a script that opens gvim when I run vimgolf, with a separate filename for each challenge, so I'd get my notes back every time I come back to the challenge. But I haven't.

Put stuff in your notes

This screenshot shows what my session might look like. I'm playing Increment, increment, increment...., which is a very easy challenge, but just for fun I'm trying to write a solution without any digits.

You can see a history of ideas I tried. The first few solutions are stupid and slow, but they work. Then I improved it. Eventually I ran out of ideas and tried a new strategy, which was fortunately better. In a paragraph at the bottom, I wrote out a few ideas for a "sub-solution" of the new strategy, which I pasted back into the main solution when I thought I'd found the best one. With the cursor at the end of the line, the ruler says my best solution is an 18.

I usually write a solution in the notes, and then try it out in the client to make sure it works. If I wrote it out wrong, I fix it. Sometimes I don't even care if I get it right. If I have a movement like 47w and I don't know exactly what number it should be, I'll put in a placeholder. As long as I know the number of digits, the stroke count will be right. I'll fill in the magic number later, if it's worth it.

My notes can get a lot longer and messier than this. Do whatever works.

Figure out what you're doing

A mark of a good challenge is that when you glance at it for even a moment, you can tell exactly what the goal is. We're not always so lucky. The input/output text shown on vimgolf.com can be misleading or even wrong. That's what diff mode is for. When I first try a challenge, I often ZQ straight out and use the diff mode feature, which shows input and output in vimdiff. If it's really nasty, I may spend more time in diff mode than the actual challenge buffer. Just be aware that diff mode uses your vimrc instead of vimgolf's, so configuration differences may be confusing.

Sometimes I'm curious how a command behaves in edge cases. So I run an experiment. Say I wonder whether dh fails a macro at the beginning of a line (knowing that h would). To find out, I'd put my cursor at the beginning of a line and run @='dhi' and see if I end up in insert mode. Or if I'm curious about how the registers behave after some command, I'll try it and run :di. Knowing the edge case behaviors of common commands is often the key to cutting a stroke.

Configure your notes

You can configure your notes Vim however you want, though keeping it close to vimgolf is less confusing. There are just a couple settings worth considering:

• set ruler: The only essential setting.
• set guioptions=a: Default gvim has buttons and menus and scrollbars. That's stupid. Keeping a is good though, because it lets you use visual mode to copy to "*, so you can paste your solution straight into the terminal. I don't actually do this much, but it's handy on long challenges.
• set list lcs=: When your solution has a tab, it's annoying that it shows up as whitespace.
• set noexpandtab: Again, solutions with tabs. Don't want those expanding to spaces.

Finish reading this article

So that's how I do it. Maybe you do something different. That's cool. You can tell me if you want.