vim plugin specific snippets

[teto]

Issue description

Some of the vim plugins need a specific vim configuration to work on nixos, we should add these to nixpkgs (via a passthru key) so that either
1/ users can reference these snippets e.g. in a home manager configuration:

      programs.neovim.plugins = [ {
        plugin = unicode-vim;
        config = pkgs.vimPlugins.unicode-vim.advisedSnippet; 
        # the advisedSnippet being: 
        # with "let g:Unicode_data_directory='${pkgs.vimPlugins.unicode-vim}/share/vim-plugins/unicode-vim/autoload/unicode'
      }

or
2/ the neovim wrapper can add these snippets to the init.vim / init.lua

The alternative of patching the plugin doesnt suit me as it makes bug reports harder and in case we dont patch correctly could taint the nixos reputation: it's best to generate a config that the user can then report to the vim plugin author.

An additionnal issue is that some plugins depend on treesitter grammars such as rest.nvim: without the grammer it triggers
no parser for 'http' language, see :help treesitter-parsers so we should be able to set that as a dependency

Here I want to collect such snippets until we agree on the proposition/naming:

• unicode.vim needs:

let g:Unicode_data_directory='${pkgs.vimPlugins.unicode-vim}/autoload/unicode'

• coq_nvim needs (see vimPlugins.coq_nvim needs aditional handling #168928):

g.coq_settings.xdg

• vim-markdown-composer can now set the path to the binary which means we wouldn't have to patch it anymore configure path to binary (or ignore it) euclio/vim-markdown-composer#69 (comment)

• sql-nvim; let g:sql_clib_path = '${pkgs.sqlite.out}/lib/libsqlite3.so'

• fzf-hoogle-nvim needs vim.g.hoogle_fzf_cache_file = vim.fn.stdpath('cache')..'/hoogle_cache.json'

• vim-grammalecte let g:grammalecte_cli_py='${pkgs.python3Packages.grammalecte}/bin/grammalecte-cli.py' (see vimPlugins.vim-Grammalecte: init at 2021-07-27 #151095)

• llm-nvim do lsp.bin_path = "${pkgs.llm-ls}/bin/llm-ls" as per vimPlugins.llm-nvim: init at 2024-02-22 #306828

[teto]

@mrcjkb @GaetanLepage after I've patched sqlite.nvim to remove the need for the snippet, I felt guilty. We should not patch plugins at the risk of maddening maintainers.

so I thought of 2 things to tackle the issue:

1. reproducing the unwrapped/wrapped nix way, aka sqlite.nvim-wrapped would have sqlite.nvim as a dependency plus the snippet let g:sql_clib_path = '${pkgs.sqlite.out}/lib/libsqlite3.so'
2. add a passthru.initRc that contains the snippet so users are free to use it directly, as well as us in the nixpkgs infrastructure (to setup tests for instance).

I believe 1 adds too much boilerplate. 2 seems more straightforward and generic. We could have an option in the neovim wrapper that auto-adds passthru.initRc when available as well.

What do you think ?

[mrcjkb]

This would be my preferred approach:

Luarocks has a external_dependencies option. We should be able to utilise this as follows:

• Update the rockspec to use external_dependencies.
• Fix the sqlite.lua library so that it can auto-detect the sqlite library and fall back to g:sql_clib_path if it isn't found.
  This would probably need a similar mechanism that luarocks uses.
• I don't think it will be possible for luarocks-nix to make use of the external_dependencies¹, so this would require an override.
  But the luarocks build should fail if the external dependency isn't present. And specifying them becomes the responsibility of the upstream plugin author.

This would be more work initially, but I think we could speed up adoption if we add a section to the neorocks best practices guide.

Footnotes

1. The format is { EXPAT = { header = "expat.h" } } ↩

[teto]

the sqlite.nvim was just an example, I did not mean it as an example to handle external dependencies, see for instance the fzf-hoogle-nvim example.

It's probably left better for another issue but I have little faith upon external_dependencies reliance. It would need a mapping between external_dependencies and all the distribs packages (if we consider only nixpkgs, luarocks-nix should be able to map the common ones, but what library name should rockspec authors use in their external_dependencies ?). Not only that but luarocks doesnt care about pkg-config for finding libraries, which is a pain for nixpkgs.
Even then, libraries might need special care. I think it's a multi-year project which I personally would refrain from. It's to handle problems like this we have nix :)
Now if anyone could make me believe this is possible, that would be the neorocks team but it's out of the scope of this issue (in my mind, we can create another ticket if you really want to tackle this).

[mrcjkb]

I see.

Something to watch out for (e.g. with the fzf-hoogle-vim example): That will only work with Nvim, but not Vim. It looks like something that should be fixed upstream.

But I see your point, e.g. for Python dependencies.
I'd prefer the passthru.initRc (for vim compatibility) or passthru.initLua (for nvim compatibility) option.
Perhaps the config could even default to using it if it's null.

luarocks doesnt care about pkg-config for finding libraries, which is a pain for nixpkgs.

I don't think a plain Lua wrapper for pkg-config would be very hard to implement. And perhaps something like that could be upstreamed to luarocks.

[GaetanLepage]

I'd prefer the passthru.initRc or passthru.initLua option.

I agree, this seems like an appropriate approach.

[teto]

The PR of what I mean: #334913

[teto]

With the related PR being merged, I will close this. Feel free to add your snippets and tag me if I've forgotten any