programs.neovim: expose generatedConfigViml

[teto]

Expose the generated viml config, this has 2 advantages:
1/ user can choose to write the generated config to a file of its choice
2/ the user can prepend/append to the config before writing it

xdg.configFile."nvim/init.vim".text = ''
" prepend some config
${programs.neovim.generatedConfigViml}
" append some config
'';

Description

Checklist

• Change is backwards compatible.

• Code formatted with ./format.

• Code tested through nix-shell --pure tests -A run.all.

• Test cases updated/added. See example.

• Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

• If this PR adds a new module

  • Added myself as module maintainer. See example.

  • Added myself and the module files to .github/CODEOWNERS.

[teto]

I have a set of local changes to generate a lua config along with a viml config. This PR also helps with that as the user could choose which file to write (i.e, write to an init.lua instead of an init.vim). It's for another PR though.,

[rycee]

I don't really know anything about this but wouldn't

xdg.configFile."nvim/init.vim".text = ''
  " prepend some config
  ${programs.neovim.generatedConfigViml}
  " append some config
'';

be equivalent to the more idiomatic

xdg.configFile."nvim/init.vim" = mkMerge [
  (mkBefore {
    text = ''
      " prepend some config
    '';
  })
  (mkAfter {
    text = ''
      " append some config
    '';
  })
]

?

[teto]

that's a good remark that should let @colinxs fix his issue without this PR. The second point about letting the user choose where to save the generated vim configuration still stands though.

[berbiche]

Can we mkdefault the init.vim to the generated vim?

That way people can override it without using mkForce.

[colinxs]

@rycee I'm not sure I follow. The issue is that I need certain parts of 'extraConfig' to appear after the plugin config and other parts to occur before. This isn't currently possible. If I understand correctly, your suggestions only helps if I completely circumnavigate the plugin system where each element of the mkMerge list corresponds to a plugin + config.

[teto]

in the example you've given, let mapleader = " " could go into the mkBefore or do you have something else in mind ? I would rather avoid having a beforeExtra / afterExtra for each plugin since it's complex for almost no gain. You can also play with the after/ subdirectory to load configuration after the main config.

[teto]

Can we mkdefault the init.vim to the generated vim?
that way people can override it without using mkForce.

@berbiche is that an advantage though ? if someone enables the neovim plugin but had already a xdg.configFile."nvim/init" in his config, he may not understand why the module doesn't generate an appropriate config.

[viniciusmuller]

This duplicate the generated plugins config, thus running the setup of every lua plugin twice and breaking the ones such as lualine.nvim who doesn't support more than one setup call. Please consider adding something like initExtra to the neovim module instead of using this workaround.

[berbiche]

This duplicate the generated plugins config
@arcticlimer

I'm not sure how this PR can lead to duplication since the only thing it adds is a nix configuration value to read the generated vim configuration.

[viniciusmuller]

Take a look at these lines:

home-manager/modules/programs/neovim.nix

Lines 296 to 298 in 7f976da

	xdg.configFile."nvim/init.vim" = mkIf (neovimConfig.neovimRcContent != "") {
	text = neovimConfig.neovimRcContent;
	};

Removing them solves the duplication issue, but it will not generate the lines if one is not using the workaround provided in this commit.

[berbiche]

Take a look at these lines:

home-manager/modules/programs/neovim.nix

Lines 296 to 298 in 7f976da

	xdg.configFile."nvim/init.vim" = mkIf (neovimConfig.neovimRcContent != "") {
	text = neovimConfig.neovimRcContent;
	};

Removing them solves the duplication issue, but it will not generate the lines if one is not using the workaround provided in this commit.

There is already a tracking issue for this #2133