Just before the beginning of my senior year as an undergrad studying math and computer science my computer broke. My university had hopped on a bandwagon of new hybrid tablet/laptop at the start of my program, requiring every student to buy these early-adopter models and designing the program around digitized hand-written content.

I ended up with the Fujitsu T4220. It was heavy, awkward to use as a tablet, and most importantly expensive to purchase and repair. Since I was nearing the end of my coursework, low on cash, and needed a laptop fast to not interrupt my studies, I went to the local electronics store and purchased the only portable computer I could afford: a Dell Inspiron Mini 10 Netbook.

Swapping to this tiny 10" Netbook required some adjustment. The keyboard was cramped, the trackpad was even worse. A few programs I commonly ran simply weren’t designed to run on such a tiny screen, causing UI components to overlap and hide functionality. One of those programs was the IDE I’d used for most of my Java-centric programming courses so far - Eclipse. I spent some time trying to customize the UI, hiding panes and maximizing my screen real estate so that I could focus on what really mattered: the code. Still, my precious pixels were being taken up by menu bars packed with useful functionality, and the startup time for Eclipse on such an underpowered machine was painful. So I started to look for alternatives. That’s when I discovered Vim.

The Struggle

My first experience with Vim is fairly typical: I opened a document, tried to type, tried to quit, got frustrated, and quickly closed what I’d decided was a terrible program.

Several weeks later, I was editing a large XML file that contained information about bus routes, and whatever other editor I was using kept maxing out the memory on my tiny netbook and crashing. Timidly, I reached for Vim because I’d heard it was light weight enough to work with larger files. To my delight, it opened quickly. I did enough research to learn to navigate around and properly close the file, then set it aside as a niche tool for working with big files.

Several weeks later, we had an assignment that involved remotely accessing a server. While my classmates struggled through some instructions for using nano to edit a file on the server, the teacher mentioned off-handedly that the server also had both Vim and Emacs installed. To my delight, I was able to use Vim over the SSH connection.

I slowly began to pick up more commands. Quickly frustrated by my tiny trackpad, I started spam-clicking l to move right. That became tedious, so I learned about w, and from there, about prefixing motions with a number to repeat them. I became a comfortable novice Vim user, able to move around and work effectively in its tiny terminal window. I still didn’t “get” Vim, but it was a useful tool that fit my needs, despite weird looks from my pair programming partners working on assignments in the computer lab. “Just use Eclipse!” they said. Try opening Eclipse with 1GB of RAM.

Kiru - the Cut

In 2012 Vim shifted from a useful tool to an indispensible one. About two years out of college, I was now working as a contractor in the Defense industry. As part of my work, I moved around quite a bit between different locations, working on projects for a few weeks or months before moving on. I rarely had the permissions (or time to wait for approval) to install custom software on the machine I worked with, and Vim became a necessity.

Around that time I found Learn to Speak Vim, the first blog post I’d read that described the keyboard shortcuts I’d learned for Vim as a language. Around the same time, I was learning about functional programming through the lens of LINQ in C#, and somehow from there made the leap to programming languages like Forth. These ideas all coalesced into one idea in my mind.

For the first time, I saw c i w not as a sequence of keys to press to change a word, but as an actual sentence. The fact that ciw and diw were similar was not just a trick for memorization, but illustrated a semantic relationship between the commands. The commands looked similar because they mean similar things, and the ways that they differed highlighted how they were different. And, using functional composition, that relationship could extend to how the commands were implemented!

I began digging into the source code for Vim, looking for this implementation pattern. I hoped that I could instrument part of Vim to generate a state machine or graph of the language underlying its commands. This could be used to help visualize the language for new learners, and to write scripts to automatically verify compatibility between Vim keybindings in other text editors.

Most importantly, such a graph structure would enable new tools to help those just starting to learn Vim. Imagine a tool that could accept an input like _iw and fill-in the underscore with all possible replacements. From there, it would be straightforward to link to the documentation for each possible substitution, or to programmatically generate examples of running each combination.

Disappointment

If you happened to click on the previous link to my Google groups question, you may have spoiled the ending to this post. The truth is that Vim’s command system is not implemented like a language at all. A relatively small subset of commands are implemented using tables that can be combinatorially combined, but most are not. There are exceptions to the rules all over the place. Special case implementations that make sense on their own don’t extend to similar commands. In the end, I found the implementation of Vim’s command language to be about as regular and formalized as English. I abandoned the idea all together.

And that’s how I came up with the idea for Gramme.