The conclusion of the Neovim & Busted testing sage is coming to a close with this new plugin: neotest-busted (GitHub mirror). In my previous post I mentioned that that I wanted to write a Neotest adapter for the busted test framework, so here it is.
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.
Let's write a ring buffer in Python! OK, that's not particularly exciting. Let's use test-drivent development, that should make things a bit more interesting. In this blog post I will go over the individual steps and my train of thought, because TDD requires a certain discipline and mindset. Why a ring buffer? A ring buffer is not quite trivial to implement because it has a couple of edge cases, but at the same time it is not hard to implement either. This is a post to follow along at home, so grab your text editor and let's get going.
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.
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.
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.
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.
Today FUTO released an application called Grayjay for Android-based mobile phones. Louis Rossmann introduced the application in a video (YouTube link). Grayjay as an application is very promising, but there is one point I take issue with: Grayjay is not an Open Source application. In the video Louis explains FUTO's reason behind the custom license, and while I do agree with their reason, I strong disagree with their method. In this post I will explain what Open Source means, how Grayjay does not meet the criteria, why this is an issue, and how it can be solved.
Recently Unity announced changes to their pricing model (archive) which have been very poorly received by their users, to put it gently. They have since backtracked (archive2) somewhat, but at this point it would not matter even if they completely scrapped their plans and went back to how things used to be. The trust has been broken and many game developers are waking up to the fact that Unity is effectively holding their project hostage. Switching from one engine to another is akin to a full rewrite, and depending on the size and progress of the project porting might not be a feasible thing to do.
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.