8.2 KiB
date: 2025-05-20 title: Exploring Neovim tags:
- software
- linux
- development
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. 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 helpful to understand how the tools we use
work.
That all 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 too 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 used
did include vim, but not nano and I found myself using cat and sed to make minor
changes just to get online so that I could get nano installed.
Some nvim Basics
This post will not be a detailed how-to on using nvim, bit 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 is a thing here. 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 probably 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 using ^ 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>fin 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 provides inline highlighting of changes and git blame support, just like what I use in VSCode
Language Server Protocol (LSP)
Prior to starting to use 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's 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 and implementing syntax highlighting, code definitions, and auto-formatting.
Tmux integration
Since I have been using tmux,
I also am 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 is used both as 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.
Not seen in my dotfiles, one of the more recent major changes is that I've swapped
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 you then have to remember when using any other computer where things are, 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 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 my own less-mature tool.