Lua

A pattern shows up in almost every Neovim user I talk to who has been using the editor for a year or two. They have their config version-controlled. They know their leader mappings by feel. They can name ten plugins they rely on daily. And they’ve been meaning to write one of their own for months. The gap between using a plugin and writing one feels larger than it actually is. Not because the work is hard, but because nothing in the getting-started path makes the shape of a plugin obvious. Every tutorial jumps to configuration DSLs, package managers, or a distribution’s opinion about layout. The mechanics underneath all of that — how Neovim actually finds and loads your code — stay invisible right up until you try to write a plugin, at which point they become the whole problem. ...

A practical starter track: install Neovim, put your config in a GitHub repo you own, and layer on a small set of plugins that turn the empty editor into something you’ll want to keep using.

One Go binary that manages its own Neovim, runs Lua tests inside the real editor, and emits LCOV/Cobertura/JUnit — no system install, no vendored framework, no shell-script gymnastics.

A community-driven Neovim distribution and a family of modular plugins — logging, diagnostics, window management, YAML, pytest, and more.

yoda.nvim is a Neovim distribution built from a family of independently useful plugins — yoda-core, yoda-window, yoda-logging, yoda-diagnostics, yoda-terminal, and adapters. Modularity was the design goal, not a refactor after the fact.