I've been working for a long time towards automatic nix dependencies for
neovim plugins (using luarocks rockspecs to discover the said
dependencies).
This is an initial commit to help me complete the missing bits.
buildNeovimPluginFrom2Nix is right now a placeholder which helps me test
in my fork a version that does a flat install of luarocks.
the vim updater will now check for attributes with the same name in the lua package set,
if that's the case the script will generate buildNeovimPluginFrom2Nix.
The current wrapper only includes vim, gvim and the man pages
(optionally). This rewrite distinguishes two scenarios, which I expect
cover the majority of use cases:
- standalone mode, when `name != "vim"`, means the user already has a
vim in scope and only wants to add a customized version with a
different name. In this case we only include wrappers for `/bin/*vim`.
- non-standalone mode, when `name == "vim"`, means the user expects a
normal vim package that uses the specified configuration. In this case
we include everything in the original derivation, with wrappers for
all the executables that accept a vimrc.
* 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.
nixpkgs creates a hierarchy of 3 folders share/runtime/<PKG_NAME> for no reason ?
makes debugging harder as well as paths longer when patching so this
removes this nested folders.
This commit shows how to convert luarocks packages into (neo)vim ones.
The advantage for neovim lua plugins to register their rockspec (aka
package definition) is that the plugin can express its dependencies and
a few metadata through it.
* tests.vim: init (moved from vim-utils.nix)
Moved tests from pkgs/misc/vim-plugins/vim-utils.nix to pkgs/test/vim.
Also reduced the amount of generated config:
- Make it possible to have an empty config when configured adequately
- removed default vim config when using native packages, it could be
source of bugs see linked issues (syntax on overrides vim highlights)
Things to watch out for:
- if you set configure.beforePlugins yourself, you will need to add set nocompatible too not to lose it
- filetype indent plugin on | syn on is not enabled anymore by default for the vim-plug installer: I dont think we should override vim defualts, at least not here since it is shared with neovim. Also sometimes it's enabled before plugins (pathogen etc,) which is not consistent.
you can run the tests via
$ nix-build -A tests.vim
first will register the config under the name init.vim which is more
appropriate for neovim.
Pass the generated config to passthru so that one can easily pass the
current config to a
raw/unwrapped neovim (helps with development).
For instance, home-manager can reference the config in $XDG_CONFIG_HOME/nvim/init.vim
without the need to wrap nvim with its config.
Currently, all the filetype and syntax are enabled *after* all the plugins has
already been loaded. Whilst this is the case for Pathogen, it's not
recommended when using VAM.
This commit applies the recommendation for:
- VAM[0]: The filetype and syntax are enabled *before* the plugins are loaded.
- Pathogen[1]: The filetype and syntax are enabled *after* the plugins are loaded.
- Plug[2]: The filetype and syntax are automatically enabled.
[0]: d9e865f3c2 (recommended-setup)
[1]: a553410f1b/README.markdown (runtime-path-manipulation)
[2]: 2f5f74e5e6/README.md (usage)
Vim Terraform expects the `filetypedetect` group to exist. However, since we were enabling the filetype and the syntax *after* loading the plugins, it was exiting with an error preventing us from generating the remote plugins manifest with the plugin enabled. See #65894 for context.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
(cherry picked from commit dadc7eb329)
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
* Allow settign gvim wrapper name independently of vim wrapper name.
* Allow setting vim wrapper name independently of derivation name.
* Refactor multiple places where name was checked for null with default
value.
This makes sure the user doesn't have to call `UpdateRemotePlugins`
manually for plugins installed through nix. A minor patch to neovim is
necessary, but it should be harmless. See
https://github.com/neovim/neovim/issues/9413 for a discussion about
the patch.
For backwards compatibility. The user may specify their own plugins
without the pname attribute. In that case the attrname of the plugin
(given as a string) is the pname.
Fixes#53112
I broke this in #52767 and didn't notice because I only tested with vim
and `requiredPlugins` is only used by neovim. This would break setups
that use string-plugins (like pathogen) with neovim.
Matthieu Coudron