blog-content/2025-05-21_nvim.md

______________________________________________________________________

date: 2025-05-21
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](<https://en.wikipedia.org/wiki/Vim_(text_editor)>) is a modal text editor and
[Neovim](https://neovim.io/) 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](https://www.youtube.com/playlist?list=PLsz00TDipIffreIaUNk64KxTIkQaGguqn),
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](https://www.nano-editor.org/) 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](https://forge.mcknight.tech/d_mcknight/dotfiles/src/commit/1e6512df4903965b6b9acf361b638c19bce9d78b/nvim)
with my nvim configuration. For the most part, I followed the excellent tutorials I linked
above from [typecraft on YouTube](https://www.youtube.com/playlist?list=PLsz00TDipIffreIaUNk64KxTIkQaGguqn).

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](https://microsoft.github.io/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](https://blog.mcknight.tech/2024/03/27/Shell-Customizations/#tmux),
I am also using [vim-tmux-navigator](https://github.com/christoomey/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](https://forge.mcknight.tech/d_mcknight/dotfiles/src/branch/main)
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](https://www.howett.net/posts/2021-12-framework-ec/).

```shell
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](https://www.gnu.org/software/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.