I don’t know exactly what it was that prompted me to start looking at vim and nvim about a week ago, but I ended up down that rabbithole this week. For the uninitiated, vim is a modal text editor and Neovim is a popular fork of vim. I have no strong opinion regarding vim vs Nvim vs emacs, but I found some good tutorials for nvim, so Neovim is the editor I chose.

Background Information

I have worked as a software developer for more than five years, which begs the question: what have I been using for a text editor and why am I bothering to write about something so trivial? Well, I have used nano for the most part when I need to edit something in a terminal, but my preference has been to paste things into a gui application for most tasks. As for why I’m writing this, I actually learned a lot about the tools that make IDEs like VSCode and PyCharm work (spoiler alert: those same tools work with nvim) and I think it is important to understand the tools we rely on.

That said, I have no previous knowledge about how modal text editors work and prior to the past week or so, I was just as trapped in vim if I managed to accidentally opened it (yes, I have searched “how to quit vim”). There are a few cases where it would have been very helpful if I had learned this sooner; some distibutions of Debian that I have used include vim, but not nano and I found myself using cat and sed to make minor changes just to get online to install nano.

Some nvim Basics

This post will not be a detailed how-to on using nvim, but I feel that I should at least cover some basics. Having used k9s and tmux, I came into this with some familiarity typing : to get at a command input. I also quickly discovered that tab-completion works in this field. The best way to get started is to open nvim and type :Tutor and then work through the interactive tutorial. I personally still use the arrow keys for navigation which do work in nvim, although hjkl is more efficient for keeping your fingers on the right keys. I also noted that home, end, etc also work in addition to the vim navigation keys ^ and $.

Lua Scripts

Beyond basic text editing, the real reason to use nvim is Lua script support. I have already updated my public dotfiles repository with my nvim configuration. For the most part, I followed the excellent tutorials I linked above from typecraft on YouTube.

Personally, I only went so far as implementing LSP integration and left the code completion and debugging tasks for an IDE to handle. I may add these to my nvim config in the future, but for now I just want to spend some more time getting used to nvim as a text editor.

To quickly review some of the functionality I find myself using thanks to plugins:

  • neotree (mapped to <space>f in my config) gives me a file tree to navigate to different files and show file status info, similar to VSCode
  • treesitter provides syntax highlighting for everything I’ve edited so far, and it automatically pulls new definitions as needed
  • Telescope provides a UI for searching file names and contents, though I admittedly haven’t used it much
  • gitsigns (mapped to <space>gb) provides inline highlighting of changes and git blame support, just like what I use in VSCode
  • which-key provides hints after starting a command and is very helpful for remembering some of my less-used key bindings

Language Server Protocol (LSP)

Prior to using nvim, I thought syntax highlighting and code completion was all built into IDEs. In fact, the Language Server Protocol is a standard method by which a program (language server) can receive information about a file and respond with information for auto-completion, definitions, references, and all the other things that differentiate an IDE editor from a basic text editor. With this knowledge, I better understand now how IDE language plugins work and how it is that VSCode seems to support every language in existence.

For nvim, I am using mason, nvim-lspconfig, and none-ls to implement LSP functionality. This combination of packages provides a system for managing language servers, syntax highlighting, code definitions, and auto-formatting.

Tmux integration

Since I use tmux, I am also using vim-tmux-navigator so that I can use the same <ctrl>+Arrow shortcut to swich between tmux panes and nvim buffers. The one repository includes both a tmux plugin and a nvim plugin, which is how the same key input is passed to the appropriate program, depending on where focus currently is. So far, I don’t really work in multiple nvim windows except that I often open neotree to have a file tree to the left of my vim editor window. I’m not sure how this might change in the future, but for now it is still very useful to move between the logical areas of my terminal in a consistent way.

Workflow Changes

In making the transition to nvim, I have found it a lot easier to manage my dotfiles repository with nvim since I don’t usually bother attaching that directory to an IDE. Now, I get syntax highlighting and visual change indicators, making it easier to roll back bad changes and make fewer mistakes in the first place! I also made some changes to my Alacritty and tmux configs to achieve a more consistent look and feel within the various terminal applications.

I am also using nvim to write and edit this post! I am particularly happy with the markdown linter mdformat which helps easily insert line breaks so that I don’t have to do it manually.

Not seen in my code repositories, one of the major changes I made is swapping the esc and caps lock keys on both my laptop and desktop keyboard. For my own reference and in case anyone wants to do the same on their Framework 13 Laptop, this was a pretty easy change using the fw-ectool.

sudo fw-ectool raw 0x3E0C d1,d1,b4,b4,w76  # Map `esc` command to `CL` key
sudo fw-ectool raw 0x3E0C d1,d1,b7,b5,w58  # Map `CL` command to `esc` key

For my desktop, I have a keyboard with QMK support, so that was straightforward to change the keymap on. Now, apart from muscle memory sometimes reaching for the esc key, it is much easier to exit modes in nvim. I’ve long held out from remapping keys on keyboards since I then have to remember where things are when using any other computer, but at this point I think its worth it so I’m not twisting my left wrist every time I need to reach esc.

What to do next?

Working through this nvim setup has gotten me thinking more about how I can optimize my daily workflow. I might look into CLI file management tools next as I do find myself using a GUI file explorer regularly, sometimes just to end up copying a path to paste into an open terminal. I briefly skimmed some search results and came up with a bunch of imperfect options, but it may be worth some deeper research and testing.

Another possibility I’ve been thinking of is trying out a tiling window manager. The more I think about what this looks like though, the more problems seem to arise like “how will that work with screen-sharing in Zoom?” and “can I use Wayland on my work computer with Nvidia graphics?” It’s an interesting concept, but I don’t know that it would be a huge benefit compared to my current setup of gTile with Cinnamon desktop.

Yet another thing I could do is start using GNU Stow to manage my dotfiles. I have my own little script for linking some of my dotfiles, but I recently learned that there’s actually a tool made for that very purpose! I’m a firm believer in not re-inventing the wheel, so if there’s an existing tool available, I would rather use it instead of maintaining something just for myself.