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.
* 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.
Vim plugins were previously represented as strings by default,
necessitating a `knownPlugins` set. Backwards compatibility is kept
(strings are still accepted), so vam plugins should continue to work.
Sometimes it's needed to override parts of `vim_configurable`, for
instance when using ENSIME (http://ensime.github.io/), in this case you
need a Python interpreter and the modules `sexpdata` and
`websocket_client`.
However overriding `vim_configurable` is quite hard as we run
`vimUtils.makeCustomizable` over the default comming from
`configurable.nix`. Therefore it's necessary to copy the code from
`all-packages.nix` and alter the parts you need: https://nixos.org/nix-dev/2017-April/023364.html
In order to simplify overriding `vim_configurable` I added an
`override` and an `overrideAttrs` function to `vimutils.makeCustomizable`
to ensure that the customization capabilities won't be lost after
altering the derivation.
Now it's possible to write expressions like this without evaluation
failures:
```
with pkgs;
let
vimPy3 = vim_configurable.override {
python = python3;
};
in vimPy3.customize { ... }
```
* vim_configurable: Add packages option to vimrcConfig
Version 8 of vim adds the concept of "vim packages": directories which
contain one or more vim plugins, in either "start" or "opt"
subdirectories. Those in "start" are to be loaded automatically, while
those in "opt" can be loaded manually. Vim detects any packages located
in one of its "packpaths".
The packages option takes a set of sets describing one or more vim
packages, and adds the derivation containing these packages to the
packpath.
* fix documentation.
Now referring to the nix prefetch scripts through their nixpkgs
derivation in order to make sure their shebang lines are rewritten
properly. Otherwise nix-prefetch-hg fails on Ubuntu (and probably
Debian) systems, where /bin/sh is not bash.
