Document nvim
This commit is contained in:
parent
954060e170
commit
7e9435622a
1 changed files with 127 additions and 0 deletions
127
2025-05-20_nvim.md
Normal file
127
2025-05-20_nvim.md
Normal file
|
|
@ -0,0 +1,127 @@
|
|||
---
|
||||
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](https://en.wikipedia.org/wiki/Vim_(text_editor)) is a modal text editor and
|
||||
[Neovim](https://neovim.io/) is a popular fork. 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 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](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 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](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'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](https://blog.mcknight.tech/2024/03/27/Shell-Customizations/#tmux),
|
||||
I also am 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 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](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.
|
||||
|
||||
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](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 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](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 my own less-mature tool.
|
||||
Loading…
Reference in a new issue