cc @timokau (just tell me if I should stop nagging you :p )

Here I've provided an home-manager example on how to use it to generate ~/.config/nvim/init.vim https://github.com/teto/home-manager/blob/8509c5821acc2cb5c83d65af68dc7c74579700ee/modules/programs/neovim.nix#L260 .

Next step (in other PRs) would be to replace the opaque configure by some more descriptive fields. I would like to pass a list of plugins (with their respective config) as is done in home-manager: it's pretty convenient.
Once the makeNeovimConfig stabilizes, we could deprecate the old wrapper (or not ^^).

I would like to pass a list of plugins (with their respective config)

I'm not sure if that is what you mean, but it would be really neat if it was possible to specify both the plugins and the related vimrc snippets (to be executed pre/post load) in the same place. This is what I currently do (I think its partly broken and assumes everything is loaded at startup though):

https://github.com/timokau/dotfiles/blob/c3340392081c126b5d1cf8cd3e7c519d1cdeb202/home/neovim.nix#L49

Yes the goal is to be able to specify the kind of config you have.
Home-manager has started going this way (to my great satisfaction): https://github.com/teto/home/blob/master/nixpkgs/hm/neovim.nix#L91. Endgoal is to have this kind of configuration in makeNeovimConfig without needing a nixos module.
But I plan to test things first with the home-manager module. My first neovim config revamp was a nightmare to maintain/rebase which is why I prefer to do it more iteratively now.

Maybe @doronbehar you could test that it doesn't break your config ? (just a rebuild). I sense you may have an advanced configuration :)

Haven't done a full review or a test, but I am on the imperative side of these kind of configurations, so my nix Neovim config is not that complicated:

https://gitlab.com/doronbehar/nixos-configs/blob/90c39b8705f8f1eca8b02dec5b0694564e98a0dd/shell-programs.nix#L189-242

thanks to the review, it's in much better shape. I fixed the manifest issue. From my point of view it's ready to be squashed and merged notwithstanding CI. It should be fully equivalent to the current state. Once that's merged, it will be easier to improve plugin support.

Alright, then 🚀?

next step will be to map some config with a plugin. I would like to make it easy to merge configs.

@teto This broke neovim.configure, eg. a simple example doesn't load the specified plugins or rc file anymore. The config file is completely empty apart from set nocompatible.

with import ./. {};

neovim.override {
  configure = {
    packages.nix.start = with vimPlugins; [ ale deoplete-nvim ];
    customRC = ''
      echoe "Hello World!"
    '';
  };
}

my bad will try to fix it by tomorrow.

@LnL7 to be honest, I had not thought of the override usecase, especially to modify the customRC part. I think it's fair to break the override scenario which is more a hacker-like scenario IMO (hoping it doesn't break for too many people). Would you mind using wrapNeovim instead ? Otherwise I could throw a warning when configure is passed.

Also this broke home-manager in some cases (doubly so since I messed up the lib.warn call to explain wrapper arguments should now be a list instead of a string an array :s Since it's not a super useful change I will revert wrap arguments to be a string again). nix-community/home-manager#1577

@teto I'm not particularly opposed to changing it but it's not something that should be changed without warning.

The snipped I showed is what's documented in various places like the the nixpkgs manual, wiki, etc... and thus will be the way almost everybody configures it currently. Given that most of the references and usages are outside of nixpkgs I consider this part of the api that should go through a deprecation cycle if it's changed.

oh shit you are right ! didn't realize this was the standard way. Gonna fix this too then.

@LnL7 I've added a commit to fix it in #102231

@teto seems like nodejs plugin is broken now, my overlay enables nodejs and disables ruby:

self: super: {
  neovim = super.neovim.override {
    extraPython3Packages = (ps: [ps.pythonPackages.jedi]);
    withNodeJs = true;
    withRuby = false;
  };
}

I get opposite effect, bin contains ruby host prog but no nodejs

❯ ls -la /nix/store/y05mzgy7lzkjxvvh73n1pym03dc4qvk5-neovim-0.4.4/bin/
total 24
dr-xr-xr-x  6 wtf  admin  192 Jan  1  1970 .
dr-xr-xr-x  5 wtf  admin  160 Jan  1  1970 ..
-r-xr-xr-x  1 wtf  admin  749 Jan  1  1970 nvim
-r-xr-xr-x  1 wtf  admin  175 Jan  1  1970 nvim-python
-r-xr-xr-x  1 wtf  admin  176 Jan  1  1970 nvim-python3
lrwxr-xr-x  1 wtf  admin   80 Jan  1  1970 nvim-ruby -> /nix/store/yhy98cq45c2fijax5kd5y1xiagsfg467-neovim-ruby-env/bin/neovim-ruby-host

ok I will look into it in a few hours.

@kalekseev I've submitted a fix. I am glad unstable is blocked for now :| maybe I would need to write some tests before further refactoring but maybe after the 0.5 release. So much to do till then.

Users of the home-manager neovim module are also broken by this.

@jonringer shouldnt' be the cae on master anmore (I have yet to check vimAlias but should be fixed too).

When I originally rebased my other PR, it was before your build fixes.

aliases do need to be fixed

$ vim
The program ‘vim’ is currently not installed. It is provided by
several packages. You can install it by typing one of the following:
  nix-env -iA nixos.vim
  nix-env -iA nixos.vimHugeX

I just developed a muscle memory around tryping vim, and a lot of my "aliases" were written in mind with this.

honestly, i think this should all be reverted, and continued in another branch.

EDIT: This has evolved over several years, and many users consume this in non-obvious ways. There's a nixos module, home-manager module, and wiki's which have code in which this does not play well with these changes.

At the very least, move this over to a different top-level attr, and allow some people some time to migrate over to the "new API" with some deprecation process similar to @LnL7 was saying.

I've tried before to do it out of tree but 1/ it was hard to maintain. 2/ It means I would drop a huge patch.

I've written both the home-manager and nixos modules. My endgoal is to make it possible to generate vim configs and write them anywhere (init.vim / .nvimrc) without the drawbacks of using -u. This allows to have per-project tailor-made nvim configurations (that could be then sharable or generated, akin to haskellPackages.shellFor ).

The goal with this PR is to make this work easier to maintain while not impacting users via a thin legacy wrapper. I kinda messed up the compatibility layer but now all should be fine. Lucky us I could fix those before it reached nixos-unstable.