TLDR; I got faster at writing (code and articles) once I stopped fighting the editor. My journey from a mouse dependent editor to a keyboard one.
As an active developer, I constantly strive to optimize my workflows. Anything that is repetitive must be automated to the nth degree. All actions that are pure, that is to say, yield the same result if the inputs are same are easy to do.
I have an elaborate zshrc (based on oh-my-zsh), Mac Automator actions, Alfred workflows to generate UUIDs or query data from my production database. These little gems save a ton of time and ensure no human errors are made.
Most of my time is spent in an editor writing code, articles, reports, etc. In all these formats, a significant chunk is navigation. I seldom write new code and I will review articles or rewrite them a bit. Any developer will tell you that code writing is jumping to locations (jump to definition, symbol and back) and then adding more code.
Since the past decade, I've been using IDEs for code writing and text editors like Sublime Text for articles and standalone scripts. Keeping aside the issue of resource usage, IDEs do a good job of allowing you to write code faster. When it comes refactoring IDEs are a boon. Having said that, they fundamentally do not solve the problem of speed/efficiency. In other words, I was still performing more keystrokes to do the same repetitive task. I saw myself constantly shuffling between the keyboard and mouse to get navigation or editing done. Shortcuts are good but they don't work across different editors. I spent a lot of time trying to configure each editor the same way.
My goal was to write faster irrespective of the content type.
Line or terminal based editors have always been a holy grail of efficiency for me. For the simple reason that they do not assume a pointer device, all actions are fine tuned to be done from a keyboard.
catonmat explains the design of keys in this article
Emacs and vim both offer the same promise, get efficient at editing via keyboard. I tried using Emacs for almost 3 months a few years ago. A half-hearted attempt that did not result in anything worth mentioning.
Vim however, has been my go to editor when logging into terminals. Whenever a config needed tweaking, I'd fire up vim. Vim ubiquity made it so that I never lost touch. Full time usage is a whole different thing though.
TLDR; Vim (or Emacs) improves your navigation speed.
At some point, I started off with gusto to move lock, stock and barrel to vim. That attempt sorely failed. I was expecting workflows to work. The basic
hjkl keys I had learnt, I thought would be enough. My productivity plummeted and I blamed on how difficult vim is.
My mistake was that I conflated the two problems:
- I want write faster
- I want to replace my IDE
Several months ago, I revisited my editor needs. I spoke to people who do use vim and started to focus on the first problem. Focusing on speed removed the friction and mental block of comparing output. I started doing non code activities on vim like articles or JSON formatting, etc.
Changes since my last attempt also made life easier:
- Neovim got LSP support and with coc I got basic JSON editing working better than Sublime
- ThePrimeagen Vim coding sessions gave me insight into practical keystrokes that help in efficient writing
- GoNeovim - a GUI based neovim instance cause I hate having a tab in iterm for my editor (personal quirk)
- My hands stay on the keyboard 90% of the time
- I do minimal wrist position changes to get anything out of the current window, be it manipulating text, navigating, performing terminal actions
- Vim motions change the way you view existing text on the screen
Vim motions need their own section. Motions take some time getting used to. Once you understand what motions want you to view text as they become significantly simpler to work with. With motions I started seeing text as markers. I won't get into the motions tutorial, the documentation does a great job of explaining each one.
Motions in itself reduced time spent in micro context switches of navigation. A simple motion of
Shift + [ meant moving up a object block. In 90% of the cases I'd land on the right place.
The curve below was accurate for me. My output decreased but for non critical tasks. That helped me stay on course to keep trying to learn.
Vim comes with a usable set of maps that you don't need to change. To make vim work for you though I've seen every single true vim developer add keymaps. They are shortcuts that you create which work only for you. I've tried so many times copying keymaps from a 3k+ stars github repo only to delete it with prejudice.
Keymaps make vim even better. My experience has been to keep trying different options. Some of my milestones have been:
- Moved leaderkey twice -
- Not using Meta keys (Alt/Cmd) - Now I do everywhere
- Tried to use plugin defaults - Now I disable them
With LSP and neovim, there was enough to move smaller projects into vim. I still don't use vim for large/complex projects that require IDE capabilities. I find the required plumbing an absolute overkill.
But that's not it!
I use Intellij which comes with IdeaVim. It gets me 80% of the way. All motions work, keymaps work. Whatever I use CoC for, is built into Idea. I had to tweak Idea to get the keymaps working identically to nvim. IdeaVim is also constantly improving; providing access to Idea IDE actions via keymaps which makes my life a lot easier.
Neovim is embeddable and I'm waiting for it to be incorporated for true vim experience. VSCode already does that with VSCodeVim
- Read blogs and watch videos (at 1.5x) to find better ways
- Github dotfiles - Scour github.com for new nvim configs
- Vimawesome - a great resource to find the latest and greatest packages
- Coc plugins - I love CoC. They keep dishing out new plugins for usecases
- Use arrow keys - Some blogs make me feel guilty but I understand why
- Limit nvim to only some usecases
- Run nvim in a GUI window - So many people have told me to use terminal
It's been a great journey so far. Using vim on a regular basis for 90% of my writing activities. I have seen visible improvement in my output and now editing is not the biggest time drain of my day.