Years with Vim

08 Jul 2018 on Vim, Tips

I really just mean three or four years when I say “Years with Vim”. I have come to rely on it for personal projects and at work. On top of this, I have invested considerable amount of time on my vim configuration. I thought it would be good to evaluate the lessons and interactions with a tool that I have come to heavily rely upon.

Before vim, I had started with Notepad++. This was a short phase in college when productivity and efficiency were not high on my radar. At one of my earlier jobs, I learned about sublime. It was cross-platform and that ctrl(cmd)+p was great. However, the people I looked upto were vim users… I saw they carried out tasks much faster on linux systems. So, I started learning and using vim.

I have worked with PHP, python, perl, Java, Javascript, HTML, and others that I am forgetting while on vim. I have had greater success with some than others. That was likely a result of the time invested in improving my workflow with each and the amount of time spent dealing with each.

How it started

When many consider vim or emacs, the learning curves will often come up. It was a factor for me when I first started with vim. It was also one of the reasons the switch to vim did not happen overnight for me.

Why is the learning curve such a big deal? I had thought about this when I first started. Almost everyone will start with the Windows operating system. From elementary school to high school, we will have done our school assignments on Microsoft Word. When introduced to the shell editors, we immediately notice that even the copy paste functionality is different. This highlights the challenge ahead in incorporating it for work. Almost all aspects of the editors have use throwing out muscle memories and many behaviors we have built for a larger part of our experiences.

And so, I followed the recommendation that many give which is along the lines of:

Incorporate it in day to day tasks and force yourself to look up functionality as you need it

I learned in the workplace. I took advantage of tasks that had a straightforward roadmap and it was just a matter of writing the lines of code. When the opportunities presented themselves, when the timelines for the tasks allowed, I would force myself to write and modify the lines of code via vim.

Vim is just a tool

Having got past the initial learning curve for vim, I fell into the trap of criticizing the use of IDEs or other editors. I had just “mastered” vim (in that, I could do my day to day job). I am more critical but in what I would like to think is a more thoughtful way. I still criticize and nudge sublime users that I consider colleagues and friends. At the end of the day, if you have a colleague that is just out of college and still relying on notepad++, it is worth bringing up greener pastures.

I now think it is naive to criticize IDEs for the typical reasons… people who built these likely put a lot of thought into them. They would not have built them if they did not believe it would boost productivity. From the use cases I have seen, it just comes down to how applicable the functionality provided is for the users who review them. If I were to work in Java again, I would consider using one of the popular IDEs like Eclipse. A more stubborn stance sticking to my preferred editor would likely be born from ignorance. It is a matter of right tools for the task at hand.

Vim with Linux

I was often working on linux systems and it was just easier to beat the learning curve than to solve each new challenge that editors not on the linux servers posed. Working on production linux servers more recently, I suspect I would be handicapped without vim or emacs familiarity. For me, vim was one of the better tools for my job.

Commandline and flexibility

Writing code and getting feedback is great. Vim encourages its users to be “closer” to the commandline. As a result, I often find that I have a tmux pane running vim and another pane, separated by vertical split, running tests on file changes. I suspect there are more people building CLI tools than plugins for specific editors that I can rely on.

Lessons in Vim - really for any editor or many other such tools

I have taken the following lessons from others and they work well. I believe they go a long way towards a smoother and more productive experience.

• start with another person’s config that has just basics you agree with
• maintain a dotfiles github repo to manage config files such as .vimrc
• address each snag you encounter
  • vimdiff colors off? update your config
  • problem loading large files? update your config and strip out plugin overhead for data files
• plugin for plugin management (ex: Vundle)
  • plugins are described by ~.vimrc
  • easy to port with each new workstation/laptop
• find ways to reduce time on the most frequent tasks
  • snippet management (ex: UltiSnips)
    • how much boilerplate do you encounter?
    • commit your snippets to dotfiles
    • make ~/dotfiles/vim/snippets the directory used by snippets plugin
• try to avoid non native plugins that are hard to maintain - unless you really need the functionality
  • for example, reliance on an external python interpreter
  • harder to maintain and port to new systems