Neovim plugins are now more often than not written in lua.
One advantage of the lua ecosystem over vim's is the existence of
luarocks and the rockspec format, which allows to specify a package
dependencies formally.
I would like more neovim plugins to have a formal description,
"rockspec" being the current candidate.
This MR allows to use nix lua packages as neovim plugins, so as to enjoy
every benefit that rockspecs bring:
- dependdency discovery
- ability to run test suite
- luarocks versioning
- rockspec metadata
the vim update.py script will check if an attribute with the vim plugin
pname exists in lua51Packages. If it does, it uses
buildNeovimPluginFrom2Nix on it, which modifies the luarocks config to
do an almost flat install (luarocks will install the package in the lua
folder instead of share/5.1/lua etc).
It also calls toVimPlugin on it to get all the vim plugin niceties.
The list of packages that could benefit from this is available at
https://luarocks.org/labels/neovim
but I hope it grows.
Note: I DO NOT resign from nixpkgs, not at all!
However, I like a clean notification inbox and I get a lot of stuff for
packages where I'm only an end-user or don't use them anymore and thus
can't help out that much.
So please consider it a measure to reduce the mental load for me when
going through my notifications ;-)
some linker flags have been added to support declarative treesitter grammars but the justification is fuzzy and it breaks several stuff on nix see https://github.com/NixOS/nixpkgs/pull/147658
* neovim.tests: ensure the graph is pulled
We'll change the plugin name to ensure the plugin is correctly pulled by
vim-plug config generation.
* neovim.tests: ensure nvim exit with error
* Revert "fix: remove trailing '/.' from vim-plug plugin paths"
The root cause if fixed by
761b2c6ff3 (diff-e4b94db9201d58bd9410739dddf92bef74e0b5f5e596c804a84ee7c580ae3f71R9)
This reverts commit d9d1a11aed.
Goal is to improve separation between packages and utilities.
Can help with autocompletion/navigate nixpkgs faster.
Also it will help standardize how LUA_PATH is exported across packages,
so that one can more easily make lua changes across nixpkgs (for
instance changing where lua modules are installed).
