Learnings after 500 commits to my vimrc
Last winter, on a Saturday, I decided to tweak my vimrc. I’d been putting it off for a long time since I felt spending time on improving and cleaning up vimrc was too luxurious; it’d be fun, but it wouldn’t pay back the invested time.
This time I determined to do myself a favor and enjoy spending a day or two working on my vimrc.
I ended up spending more than three months and making around 500 commits to my vimrc, and I still work on it from time to time – I didn’t intend it, but coincidentally it’s precisely 500 commits when I try to publish this article.
I’ve learned more than I’d learned in the past ten years during this time.
It was a fun and frustrating journey. I want to share what I’ve learned along the way and how happy I am now.
Table of Contents
What I have done
I started by deleting unused plugins and configurations, and then I looked for plugins to fix and improve a few things that were bothering me.
Once I got started working on it, I couldn’t stop. Learning how things work and improving my daily workflows with the new knowledge was too fun and exciting.
Books
To better understand vim help pages and plugin documents, I started checking out books.
- Learning the vi and Vim Editors, 8th Edition,
- Practical Vim, 2nd Edition,
- Modern Vim,
- Mastering Vim, and
- The VimL Primer.
Especially, Learning the vi and Vim Editors was good to brush up on my vim skills, and The VimL Primer was helpful to learn vimscript.
I could access all the books freely thanks to the O’Reilly membership that my employer provides me.
I checked out chapters that interested me instead of reading cover to cover. Reading books with the membership feels like listening to music with a music streaming service instead of having to buy CDs.
vimrcs
I read a few awesome guys’ vimrc, such as
- Junegunn, who wrote Plug and fzf, and
- wookayin, who wrote gpustat and happens to be my former co-worker.
I learned many things from the books and vimrcs, but I still often had to read help pages and Stack Overflow threads to achieve what I wanted.
vimscript
I learned that Vimscript is not that hard once you’re good with vim.
When I learn a new programming language, I start writing tests with it. This method is called Test-Driven Learning.
Writing test code is an excellent way to learn a programming language because
- You learn the testing framework of a language in the early stage.
- You learn by writing working code.
- You have working documentation.
Vader is a vimscript testing framework that is written by Junegunn. This is my Test-Driven Learning project using Vader: Github project.
I wrote a vim plugin Mintabline to solve a problem that Neovim doesn’t show the tabline properly for terminal buffers.
I feel powerful after learning vimscript.
How to troubleshoot vim and plugins
I used to spend hours and days to find out the reason for a vim issue, but now It usually takes no more than 30 minutes using the methods that I’ll introduce soon.
Knowing how to fix issues is the key to utilizing vim to its full power – which is valid for any other technology.
I used to keep my plugin list lean to avoid randomly happening errors and slowness; I often didn’t know where I should start to troubleshoot a problem.
I’ve tried tens of plugins for the past few months and faced loads of issues; it sometimes took a few weeks to resolve.
Vim plugins are powerful since they can control vim without having to reside in a sandbox or container, but this makes it harder to debug an issue.
Showing error messages with :message
When you face an issue, the first thing you should do is to read error messages carefully, but an error message could quickly disappear when you do some actions in vim. In this case, you can use the :message command to bring the message back.
However, it’s impossible to easily copy the message or have the result window open while troubleshooting. You can load messages into a buffer using this function to tackle this problem (source wiki).
function! TabMessage(cmd)
redir => message