Improve config files and rtp handling about nixvim

[stasjok]

Whatever approach we use, config will be installed to environment.etc.* on NixOS and xdg.configFile.* on home-manager. If there's an equivalent for nix-darwin we should consider installing there too.

Anything in the wrapper (such as -u or exporting variables) would be in addition to that.

So I'm trying to think if there's any downsides to doing this universally, without a wrapRc option 🤔

I'm not aware of any side effects, if neovim is ran with -u /home/user/.config/nvim/init.lua (standard XDG_CONFIG_HOME along with all other neovim configs) and $MYVIMRC is set to it's path.

[MattSturgeon]

Potentially we can manage rtp partially with wrapper args, in that case we can even drop wrapRc completely and just place init.lua to filesPlugin.

We may be able to do that with the -c option, which allows specifying additional vim commands from the CLI.

There's also --cmd, which is like -c except it is run before the init file.

However this wouldn't allow us to drop wrapRc, since that is mainly intended for specifying the init file to use via -u.

But this is debatable, maybe managing rtp paths as the first lines in init.lua is enough plus allow users to add paths with raw lua.

I think there's value in the rtp changes being shown transparently in nixvim-print-init.

Or it can mixed approach: user config path is added with command line args (so that the directory with init.lua is known to neovim), other paths are managed in init.lua.

Not sure what you mean by "directory with init file is known to neovim"?

My understanding is neovim computes this dir internally using APP_NAME, and using -u to specify the init file essentially means this dir is not used anyway?

But I'm not confident I fully understand this.

I think I need to read https://neovim.io/doc/user/starting.html#initialization a few times 😂
In particular, under point 7:

If Nvim was started with "-u {file}" then {file} is used as the config
and all initializations until 8. are skipped. $MYVIMRC is not set.
"nvim -u NORC" can be used to skip these initializations without
reading a file. "nvim -u NONE" also skips plugins and syntax
highlighting.

[stasjok]

We may be able to do that with the -c option, which allows specifying additional vim commands from the CLI.

There's also --cmd, which is like -c except it is run before the init file.

However this wouldn't allow us to drop wrapRc, since that is mainly intended for specifying the init file to use via -u.

Year, I was completely wrong about it. I thought that since --cmd is run before init.lua, I can set rtp there, and Nvim will find init.lua in rtp, but that's not the case. In that case wrapRc is unavoidable (or $VIMRUNTIME can be set manually in wrapper args, but it's basically the same thing).

With this information fourth point is invalid. There is not a single reason to use --cmd args for rtp, only -u for init.lua. Settings rtp and packpath in extraConfigLuPre with mkBefore is perfectly OK. Fourth point can be changed to similar issue as filesPlugin, but with home-manager. Nixpkgs by default is adding plugin dir to rtp with set rtp^=/nix/store/xxx-vim-pack-dir. In this case plugins are first in rtp, user configs only after. My suggestion to modify rtp by default should fix that too.

[MattSturgeon]

I'm also trying to wrap my head around whether there's ever a good reason to have a user-configured wrapRc option at all?

The only time I can think of where specifying the vimrc via -u isn't needed would be when installing via home-manager, since we install to xdg config.

Even in that scenario, I don't think setting the vimrc with -u really does any harm though?

Historical context

The wrapRc option is basically a copy of pkgs.wrapNeovimUnstable's argument of the same name. Although we implement it slightly differently to position parts of the initial file correctly.

The rtp modification to get an "isolated" config is a more recent change (c359761), that is not part of the nixpkgs implementation.

IMO the isolated rtp doesn't conceptually relate to specifying the vimrc via the wrapper, so this may also benefit from either being a separate option or not being configurable at all.

Simple option:

Can we just remove the wrapRc option entirely and always isolate the config, use -u in the wrapper, etc?

Is anyone aware of a legitimate use case for setting wrapRc = false?

[traxys]

None comes to mind, but maybe someone relies on it and will explain their use case if we do something with it

[stasjok]

Is anyone aware of a legitimate use case for setting wrapRc = false?

When -u is used $MYVIMRC is not set and it is hard to get init.lua path from inside nvim. I personally don't want -u to be used in home-manager. LuaSnip for example by default loads paths relative to $MYVIMRC (maybe it fixed now, don't know), some other plugins can use it too.

[MattSturgeon]

When -u is used $MYVIMRC is not set

True, but we could export that ourselves in the wrapper

[stasjok]

True, but we could export that ourselves in the wrapper

Still I think it's better to put init.lua in xdg_config_home to better emulate regular, non-nix neovim. So I'd say to make this option internal/readonly and set it to true by default. Home-manager wrapper can override it to false. In other cases it's unavoidable (unless maybe settings XDG_CONFIG_HOME in the wrapper? But it's worse than setting -u, because XDG_CONFIG_HOME will be needed in internal terminal and other subprocesses). I don't think this is a big burden.

If -u would be set, I think I would want to circumvent it somehow to undo it in my config.

[MattSturgeon]

Whatever approach we use, config will be installed to environment.etc.* on NixOS and xdg.configFile.* on home-manager. If there's an equivalent for nix-darwin we should consider installing there too.

Anything in the wrapper (such as -u or exporting variables) would be in addition to that.

So I'm trying to think if there's any downsides to doing this universally, without a wrapRc option 🤔