false by default.
I noticed checkhealth complaining about it
Which made me realize the providers ignored user config and were always
using default config, hence the backport.
nvim-treesitter installs tons of queries that are picked up
by neovim even though we sometimes dont want those queries.
This makes it possible to install grammars without nvim-treesitter which
becomes more and more a repository like nvim-lspconfig, aka a repo that
lists others.
buildNeovimPluginFrom2Nix was cargo-culted from buildVimPluginFrom2Nix
but this doesn't make sense.
From2Nix referred to a way of building plugins that is not used anymore
so buildVimPluginFrom2Nix could be renamed too.
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).
