pluginst/blink: add blink.nvim

[Balssh]

Hi there, this is my first contribution to a Nix related project (besides some flake configs). I try to add this plugin: https://github.com/Saghen/blink.cmp which wants to be an alternative to nvim-cmp.

I'd like to hear any feedback and tips for improvements. Also how can I actually test this locally? Many thanks!

[MattSturgeon]

Also how can I actually test this locally?

Firstly, you should write a unit test in the style of other tests under tests/test-sources/plugnis/by-name. Once done, you'll be able to run tests blink or tests -i (to search interactively).

To access the tests command, enter a devshell either using direnv-nix or the command: nix develop

Secondly, you can take advantage of nix flake lock on an external nixvim config repo (such as your nix config):

# Override to your locally cloned nixvim
# You'll have to re-run this if ../nixvim is modified
nix flake lock --override-input nixvim ../nixvim

# Override to a remote repo
nix flake lock --override-input nixvim github:Balssh/nixvim/add_blink

# Undo un-committed changes to your lockfile
git restore flake.lock

[Balssh]

Also how can I actually test this locally?

Firstly, you should write a unit test in the style of other tests under tests/test-sources/plugnis/by-name. Once done, you'll be able to run tests blink or tests -i (to search interactively).

To access the tests command, enter a devshell either using direnv-nix or the command: nix develop

Secondly, you can take advantage of nix flake lock on an external nixvim config repo (such as your nix config):

# Override to your locally cloned nixvim
# You'll have to re-run this if ../nixvim is modified
nix flake lock --override-input nixvim ../nixvim

# Override to a remote repo
nix flake lock --override-input nixvim github:Balssh/nixvim/add_blink

# Undo un-committed changes to your lockfile
git restore flake.lock

Thanks! Will do this along with all other requests in the next commits.

[Balssh]

Will continue working on this after https://github.com/NixOS/nixpkgs/pull/348105 is merged

[MattSturgeon]

@Balssh if you're stuck on anything just shout. IDK your timezone (I'm GMT), but I don't mind arranging a call or chatting on Matrix if there's anything you want to go over or need help with.

[Balssh]

@Balssh if you're stuck on anything just shout. IDK your timezone (I'm GMT), but I don't mind arranging a call or chatting on Matrix if there's anything you want to go over or need help with.

Thanks for your offering, right now I'm testing stuff on how to declare settingsOptions. Sorry if the multiple pushes are bothering, I can resolve to using local nixvim fork.

I was stuck because I didn't realise I had to provide description string at the end of a setting declaration. Got it now and hopefully the remaining settings I want to define will go smoothly. At last will look into implementing tests.

[Balssh]

@MattSturgeon Ok, now I think I'm in a happy place with the plugin, I'm a bit unsure what tests to write for this. I looked into the nvim-cmp tests examples but it's not very clear what it's being tested. For example, the I could write a

keymap-test = {
    plugins.blink-cmp = {
        enable = true;
        settings.keymap = {
            show = "<C-space>";
            hide = "<C-e>";
            accept = "<C-y>";
            select_prev = "<C-p>";
            select_next = "<C-n>";
            show_documentation = "<C-space>";
            hide_documentation = "<C-space>";
            scroll_documentation_up = "<C-b>";
            scroll_documentation_down = "<C-f>";
            snippet_forward = "<Tab>";
            snippet_backward = "<S-Tab>";
          };      
    };
};

But other than making sure settings.keymap exist and the format is good, is anything else tested? Thanks

[MattSturgeon]

Most of our tests are just checking that a) the nixvim configuration evaluates without any errors or warnings and b) neovim can run the resulting init.lua without printing any warnings to the console.

It is possible to add additional assertions to the nixvim configuration, or add lua assertions to extraConfigLua, however almost none of our tests do anything that specific.

The example you suggested would be a great test case. We'd also ideally like an "empty" test (just setting enable = true for your plugin) and a "defaults" test (setting each settings option explicitly to the upstream plugin's default value).

The nvim-cmp tests probably aren't the best tests to be looking at, though. IIRC they are fairly complex compared to most other "normal" plugin's tests.

[Balssh]

Fair enough, will write them tomorrow probably, thanks!

[Balssh]

Hmm I'm having some trouble with tests:

[devshell]$ tests blink-cmp
Running 1 tests: blink-cmp
error: attribute 'null' in selection path 'checks.x86_64-linux.null' not found
Test failure

[MattSturgeon]

$ tests blink-cmp

My mistake, it's probably something more like plugins-by-name-blink-cmp-default.

You can use tests -i to filter through the tests interactively.

[Balssh]

Yup, tests -i works, but something weird happens as it seems to fail while trying to download prebuild binaries:

Running 1 tests: plugins-by-name-blink-cmp-default
warning: Git tree '/home/balssh/Projects/nixvim' is dirty
copying '/home/balssh/Projects/nixvim/' to the store
error: builder for '/nix/store/qdax56jw3y0ykh3l0cz1pn2x63ir34vj-empty.drv' failed with exit code 1;
       last 10 log lines:
       > ERROR: Error detected while processing /nix/store/x8lf69b2618vkfl6m1gcp3p0lzk48xlv-init.lua:
       > E5113: Error while calling lua chunk: ...-unwrapped-0.10.2/share/nvim/runtime/lua/vim/_system.lua:244: ENOENT: no such file or directory
       > stack traceback:
       >        [C]: in function 'error'
       >       ...-unwrapped-0.10.2/share/nvim/runtime/lua/vim/_system.lua:244: in function 'spawn'
       >   ...-unwrapped-0.10.2/share/nvim/runtime/lua/vim/_system.lua:335: in function 'system'
       >  ...ackages/start/blink-cmp/lua/blink/cmp/fuzzy/download.lua:76: in function 'get_git_tag'
       >      ...ackages/start/blink-cmp/lua/blink/cmp/fuzzy/download.lua:24: in function 'ensure_downloaded'
       >        .../myNeovimPackages/start/blink-cmp/lua/blink/cmp/init.lua:8: in function 'setup'
       >     /nix/store/x8lf69b2618vkfl6m1gcp3p0lzk48xlv-init.lua:9: in main chunk
       For full logs, run 'nix log /nix/store/qdax56jw3y0ykh3l0cz1pn2x63ir34vj-empty.drv'.
error: 1 dependencies of derivation '/nix/store/r04vm7n27zdy3lj0nm3qnsd88w2bf205-plugins-by-name-blink-cmp-default.drv' failed to build
Test failure

Now, this is a bit weird as I can run the plugin just fine in my nixvim config, and also because I have set the option https://github.com/Saghen/blink.cmp/blob/465dc89dc63bef41fa97a133a1b4f51400048829/lua/blink/cmp/config.lua#L249 to false in my latest test: https://github.com/nix-community/nixvim/pull/2404/files#diff-8552feb0d654595acc17cba194c95cc42f5330bc99d3b9a2fbd3d48c75ac18e4R42. It's interesting because I didn't set that download=false in the plugin's config I'm using.

I'm not sure if the problem stems from the plugin's init flow, or from nixvim's. Is there a way to check the nixvim config's while running a certain test?

[MattSturgeon]

[the test] seems to fail while trying to download prebuild binaries:

This is due to the nature of how the tests are implemented.

A nix test is usually a derivation; if the derivation builds successfully the test is said to have passed. If the derivation fails to build, then the test has failed.

For our tests, this means we are running nvim within a derivation buildscript.

Derivation buildscripts are run in a sandboxed environment, to ensure that derivations stay "pure" and reproducible. This is a good thing, even for tests, as it means every time you run the test (or build any derivation) you should get the same output.

But in this case, it means you can't download things within the test.

There's a few solutions:

1. Set things up (e.g. using source fetchers), so that we don't need to download at "runtime"
2. You could disable the runtime component of the test, so we only test the nixvim module eval.

Unless you know a good way to do option 1, option 2 is fine. This is done by setting the option test.runNvim = false in your test module(s).

It's interesting because I didn't set that download=false in the plugin's config I'm using.

If there's a way to disable downloading things, that would be the best solution.

[Balssh]

If there's a way to disable downloading things, that would be the best solution.

Well it looks like it is, but can I inspect/list what nixvim's config is set to for the plugin I'm testing? I've set the downloading to false in the test I've written, but either it doesn't get picked up by nixvim, I declared it wrongly or there is a bug in the plugin itself.

For now I've set test.runNvim = false;. I think my PR is ready for review now.

[Balssh]

Just missed a few things, if we're going to offer the options in settingsOptions we want to make sure we're testing them in the test module.

Sorry, hurried and messed them up :face_holding_back_tears: Should be defined now.

[Balssh]

Thanks for having patience with me!

[khaneliman]

@mergify queue

[mergify[bot]]

queue

✅ The pull request has been merged automatically

The pull request has been merged automatically at a4c3ad01cd0755dd1e93473d74efdd89a1cf5999

[mergify[bot]]

This pull request, with head sha a4c3ad01cd0755dd1e93473d74efdd89a1cf5999, has been successfully merged with fast-forward by Mergify.

This pull request will be automatically closed by GitHub.

As soon as GitHub detects that the sha a4c3ad01cd0755dd1e93473d74efdd89a1cf5999 is part of the main branch, it will mark this pull request as merged.

It is possible for this pull request to remain open if this detection does not happen, this usually happens when a force-push is done on this branch add_blink, this means GitHub will fail to detect the merge.