the neovim mechanisms generate provider rc configuration such as:
vim.g.<LANG>_host_prog=$out/bin/nvim-<LANG>
In home-manager, we want more control over it, e.g., to pass it via
command line or in init.lua.
We also want to retrieve the generated packpathDirs so that we can link
it in the expected $XDG_DATA_HOME folder so that we then dont have to
tell neovim where look for it anymore.
this way home-manager can link the packpathDir in
~/.local/share/nvim/site which makes package discovery work without
needing to `set packpath` (making the wrapper further useless).
checkInputs used to be added to nativeBuildInputs. Now we have
nativeCheckInputs to do that instead. Doing this treewide change allows
to keep hashes identical to before the introduction of
nativeCheckInputs.
This introduces a patch that improves binary reproducibility since changes in
ordering of the generated code indeed cause changes in the compiled code.
Additionally, since neovim embeds luajit-compiled bytecode into the nvim binary,
we are impacted by https://github.com/LuaJIT/LuaJIT/issues/626 . It is possible
to switch to lua 5.1, but that'd be a regression (luajit has much better
performance and some plugins depend on it, like for example Noice and Lazy).
Disabling `COMPILE_LUA` at build time would cause a runtime penalty each time
neovim starts. Instead, we run luagit with those security settings disabled for
the build-time code generation.
(Note to self: for a minimized testcase this seemed to help at
975ec13f5d5aefcac1dbb15fa867e660e07c93a1 but no longer at
03080b795aa3496ed62d4a0697c9f4767e7ca7e5 of luajit, which is surprising since
that commit doesn't look super relevant. _Also_ surprisingly it does seem to
work in the context of the neovim code generation, though, so that might be
good enough...)
Also, some of the code generation (using mpack and tables) still relies on
stable table ordering. This should eventually be fixed, but as a workaround
we use the luajit-with-stable-string-ids for those generators as well.
Fixes#207841
Avoids confusion: `vim-full`'s build-time features are configurable, but both
`vim` and `vim-full` are *customizable* (in the sense of user configuration).
right now the src is ignored in:
```
lush-nvim = buildNeovimPlugin {
pname = "lush.nvim";
version = "2022-08-09";
src = fetchFromGitHub {
owner = "rktjmp";
repo = "lush.nvim";
rev = "6b9f399245de7bea8dac2c3bf91096ffdedfcbb7";
sha256 = "0rb77rwmbm438bmbjfk5hwrrcn5sihsa1413bdpc27rw3rrn8v8z";
};
meta.homepage = "https://github.com/rktjmp/lush.nvim/";
};
```
which is very confusing. With this PR, we correctly override the src and
the version of the package. We introduce a rockspecVersion attribute of
lua package to be able to still find the rockspec when the
"version" field needs to be different than "rockspecVersion".
Fixes https://github.com/NixOS/nixpkgs/issues/193070
Basically it was hard to install both
nvim-treesitter.withPlugins (
plugins: with plugins; [
tree-sitter-c
tree-sitter-lua
tree-sitter-org-nvim
]
));
and nvim-treesitter
It also simplifies some nix code.
Stops using ex mode when running neovim for remote plugin manifest generation, since that leads to errors in more recent neovim versions with various plugins.
neovim commit that breaks this plugin generation: https://github.com/neovim/neovim/commit/64d147b
Adding "packages" to the neovim distribution triggers the wrapping of
the derivation. This is because it tries to "set packpath/rtp" in the
init.vim.
If we set these arguments via --cmd instead we can avoid to create an
init.vim, which can be useful if we want to wrap an init.lua later on
(in home-manager for instance, we dont want to generate viml code).
Also removes the support for "configure" in makeNeovimConfig and
configure.plug / configure.vam packages in the compatibility layer
'legacyWrapper'.
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).
