Update post with which-key and current date
This commit is contained in:
parent
e34de3a776
commit
c3a9df0fa4
1 changed files with 0 additions and 142 deletions
|
|
@ -1,142 +0,0 @@
|
||||||
______________________________________________________________________
|
|
||||||
|
|
||||||
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 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
|
|
||||||
|
|
||||||
### 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.
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue