Sometimes you want to have a set of Vim settings specific only to a certain project. There are many tips out there how to achieve such a setup, but most of them expose the user to serious security risks. I am going to describe the fundamental problem and how to solve it. TL;DR: use the vim-addon-local-vimrc plugin.
Recently I have switched my Neovim setup to using the new native Vim package system directly instead of relying on a plugin manager. I had to use Git submodules for another project anyway, so I figured I could combine them with Vim packages and see how that might work out. It is actually working pretty well, to the point where I don’t think that I will be returning to plugin managers for the foreseeable future.
A lot of new Neovim plugins come with a setup function which lets you specify the settings of the plugin. Users are expected to call that function with a table as arguments which contains the user’s personal settings to override the defaults. This works, but Lua is all about tables, so let’s look at an alternative.
Two months in the making, it is time to finally release my new Neovim plugin officially: nvim-ts-rainbow2 (GitHub mirror). This plugin uses Neovim’s built-in Tree-sitter support to add alternating highlighting to delimiters. This is usually known as “rainbow parentheses”, but thanks to Tree-sitter we are not limited to parentheses, we can match any kind of delimiter, such as tags in HTML or begin/end blocks in some programming languages.
Wait what, again? Yes, another rainbow delimiter plugin, a fork of a fork. The previous one nvim-ts-rainbow2 was built as a module for nvim-treesitter because that is what the original plugin did and what everyone else was doing. However, nvim-treesitter is deprecating the module system. This means nvim-ts-rainbow2 will eventually stop working, so we will need a new rainbow plugin sooner or later anyway.
No, not another rewrite. Much better than that: the long-standing ugliness of highlighting being limited to only one node at a time has been fixed. Previously only one opening node and one closing node could be highlighted. This was perfectly adequate for most languages where you have one opening parenthesis and one closing parenthesis. However, consider HTML: we want to highlight the opening and closing tag, but if we highlight the entire top-level node we also highlight the attributes of the tag, which looks too vibrant. The alternative was highlighting the tag name, but this left the angle brackets without highlighting, which looked jarring as well.
I have just published version 0.3.0 of rainbow-delimiters.nvim (GitHub mirror). This update brings in a number of the usual improvements to to queries and strategies, but more importantly it also makes configuration at runtime more flexible, but most importantly in light of the current date it also includes a fun little Christmas-themed strategy.
The most annoying part about writing plugins for Neovim has been the lack of a good test framework. There are a couple of frameworks, and Vader has been my favourite so far, but they all have their downsides. This made me wonder: why limit myself to Vim/Neovim test frameworks? We have a full Lua runtime, and other people already have solved the testing problem for Lua. Busted does 90% of what we need, so let’s fill in the remaining 10%. The following is based on my experience with adding tests to rainbow-delimiters.nvim.
Yo dawg, I heard you like Neovim, so I put a Neovim inside your Neovim, so you can edit while you edit! Ahem… anyway, in my previous post I proposed a plugin which would make it easier to control an embedded Neovim from within Neovim. So I went ahead and wrote yo-dawg.nvim (GitHub mirror), named after the “Yo dawg” internet meme.
In a previous blog post I wrote about testing Lua scripts in Neovim using the busted test framework. Today I want to look at how to debug Lua scripts in Neovim using the Debug Adapter Protocol (DAP). Just as before with busted, our problem is that we need to use Neovim as our Lua interpreter because we want to use Neovim’s Lua API. At the same time, the debug adapter expects the Lua interpreter to conform to Lua’s command-line interface. That’s right: we need another command-line interface adapter.