What do these two things have in common?

The best thing about Vim, the reason why I have come to love this particular piece of software so much, is that it can be so incredibly personal and unique for each user. I love the way that I can effectively have my own personal Vim designed by me - specifically for me. What makes this possible is the .vimrc file. The .vimrc file can be tailored a bit at a time as my workflow changes. And my .vimrc changes as my knowledge and my skill level, with Vim itself and with programming in general, increases.

This past summer my 11-year-old son found a fallen tree branch, about two meters long, on the forest floor while we were camping in the mountains. He began whittling on the branch and using it as a walking stick. I watched him make some designs on the bark with his pocket knife. He took the walking stick home with him from the mountains and he continued working on it, carving more designs, whittling the wood to make a placeholder that fit his hand perfectly.

Recently, I began seeing the parallels between my son's walking stick and my .vimrc file. By editing my .vimrc file, adding plugins using Vundle ( Vundle itself being a brilliant plugin ), making leader key bindings, finding the themes that I like working with, adding all sorts of settings, tweaking just about everything - I am making it more and more practical for me. I am making the walking stick that I want to take with me on a hiking trail.

In customizing my .vimrc, Vim becomes a tool that can be any shape or colour I want it to be. And I have found that the challenge of sharpening this tool is very satisfying.

From running the vimtutor command for the first time ( where you can first learn how to exit the initially weird environment that is Vim ) to full-on expert in your particular way of working - your .vimrc can change and grow - getting sharper and sharper. I like to think of the .vimrc file ( or other dotfiles such as .bashrc, .zshrc, .tmux.conf, .gitconfig ) as weirdly creative yet extremely practical canvases on which the growth of a software developer is inadvertently charted.

Of course, I do not change and experiment with my .vimrc file in order to "chart growth". I do it because I am seeking to become a more proficient and efficient developer. But, if I were to look back at the previous versions of my dotfiles, I would definitely see growth and increased understanding. An increasing understanding of Vimscript, sure, but also of programming concepts in general. And, most importantly, the various dotfile versions chart an increased understanding of what works for me.

Everybody uses Vim differently.

For example, Kelsey Hightower, Staff Developer Advocate - Google Cloud Platform, has said publicly that he uses Vim without any plugins whatsoever. I listened to a podcast in which he explained that writing code with a simple Vim setup, without syntax highlighting enabled, helps him to focus on each line. And that sounds cool to me. While foregoing plugins is not something that I feel I want to do, the great thing about Vim is that your configuration ( or lack of configuration ) is all yours to do with what you want. If you want to code with Vim out of the box without plugins and you feel that helps your work - that is great. 💯

I have a folder containing my dotfiles under version control for awhile now and this is what I see when I run git log --oneline on that repo:

Each one of the commits represents at least a few things I have learned to make my workflow more efficient.

For me, change is what my .vimrc is all about. It is a living document. Experimentation is all.

Sometimes I work with a vim that looks like this:

And sometimes it looks like this:

I will try a particular plugin for awhile, and if I find it useful, then great - I have made a discovery to help my work. But if I find I do not like it, it is an easy process to uninstall it using Vundle.

I have learned some very useful things through the book,
Learn Vimscript the Hard Way by Steve Losh. There is a free HTML version - or you can purchase a paper copy or an ebook through the website.

I can not say enough about the wonderful repository,
Awesome Vim.

I have also proudly ripped off some great stuff from the repository, The Ultimate vimrc.

Plus, a special mention to the dotfiles of Ben Orenstein.

Also, Vim-Galore has been an amazing help. Of course, I have never taken from these open source files wholesale. I digested the changes as I went along - a bit at a time.

The resources above, and many other that can be found by searching Google and GitHub, are plenty for anyone wanting help in making the most awesome walking stick - tailor made for themselves.

Vim is a tool that actually uses its own programming language - and a fascinating one at that. Vim source code is written in the C language - but Vimscript ( mentioned earlier in this post ) is what one uses to write plugins and add functionality onto Vim. While I do not use Vimscript in my day to day work beyond customizing my Vim configuration - I quite like the challenge of learning Vimscript and slowly improving my use of it. Eventually, I will use it to write my own plugins for use in my own work. I can then share those plugins with anyone else who might be interested. If that is not a rich piece of software - I do not know what is.

For more advanced features, I like this video by Alisue Lambda:

And I like these two by Chris Toomey:

The benefits of writing code with a modular editor take a bit of work and practice to realize - but are well worth the effort.

The Vim way of editing code can also be achieved and transferred to other editors - such as VS Code ( also incredibly rich software ) with it's wonderful community and collection of extensions - including a terrific one called vscodevim.

Or to Atom - with its lightness and speed and a very well made vim emulation package.

I use VS Code and Atom from time to time - depending on what I am working on.

Classic Vim, VS Code, or Atom - all three are brilliant open source software. With the Vim key binding plugins available, I can keep consistency between my tools.

Note to myself: Always be searching the forest floor.

Making your own walking stick is simply a better feeling than buying one. You own the tool in a way that you would not otherwise.

The biggest lesson I have learned for myself through making my own programming walking stick?

Continually find what works for me - and go with it 🤓