diff --git a/2025-05-20_nvim.md b/2025-05-20_nvim.md index e9663b2..5f10444 100644 --- a/2025-05-20_nvim.md +++ b/2025-05-20_nvim.md @@ -13,7 +13,8 @@ ______________________________________________________________________ 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](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), +[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 @@ -21,29 +22,28 @@ so Neovim is the editor I chose. 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 +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. +tools work with `nvim`) and I think it is important to understand the tools we rely on. -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. +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`, bit I feel that I should at +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 is a thing here. The best way to get started is to open `nvim` and type +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 probably more +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 using `^` and `$`. +etc also work in addition to the `vim` navigation keys `^` and `$`. ## Lua Scripts @@ -62,30 +62,30 @@ To quickly review some of the functionality I find myself using thanks to plugin - neotree (mapped to `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 +- gitsigns (mapped to `gb`) 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 +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's editor from a basic text editor. With this +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 and implementing syntax highlighting, code definitions, and auto-formatting. +servers, 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 +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 ``+`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 +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 +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. @@ -100,7 +100,11 @@ changes and make fewer mistakes in the first place! I also made some changes to 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 +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/). @@ -113,7 +117,7 @@ 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 +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`. @@ -129,10 +133,10 @@ Another possibility I've been thinking of is trying out a tiling window manager. 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. +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 my own less-mature tool. +would rather use it instead of maintaining something just for myself.