Update which-key keybind spec about nixvim

[pkulak]

Not terribly related... but does anyone know how to keep which-key from spewing warnings every single startup?

[clemenscodes]

Not terribly related... but does anyone know how to keep which-key from spewing warnings every single startup?

I don't know of any native setting to do that, but you could downgrade which-key to a version prior to the breaking change:

{pkgs, ...}: {
  programs = {
    nixvim = {
      plugins = {
        which-key = {
          enable = true;
          package = pkgs.vimPlugins.which-key-nvim.overrideAttrs (oldAttrs: {
            src = pkgs.fetchFromGitHub {
              owner = oldAttrs.src.owner;
              repo = oldAttrs.src.repo;
              rev = "0539da005b98b02cf730c1d9da82b8e8edb1c2d2"; # v2.1.0
              hash = "sha256-gc/WJJ1s4s+hh8Mx8MTDg8pGGNOXxgKqBMwudJtpO4Y=";
            };
          });
        };
      };
    };
  };
}

[khaneliman]

Not terribly related... but does anyone know how to keep which-key from spewing warnings every single startup?

While looking through the source, I did see https://github.com/folke/which-key.nvim/blob/6c1584eb76b55629702716995cca4ae2798a9cca/lua/which-key/config.lua#L26 which makes it look like you can suppress the warnings about mappings with the notify = false option.

[MattSturgeon]

Thanks for making an issue and for being so detailed - this is very useful!

I've been meaning to look into this for a few days now.

We could use our transitionType to convert old values to the new type, but I think the best bet is to incorporate this as part of a general update/refactor of the module to use our new-style freeform settings option.

[michaelhthomas]

Looks like v3 comes with several other breaking changes to configuration options, so to me, it makes sense to just fully overhaul the module as well (in the spirit of which-key v3 being a complete rewrite)

[MattSturgeon]

(sidenote: in to-lua.nix the comment says:

        If this option is true, attrsets like { __unkeyed.1 = "a"; b = "b"; }
        will render as { "a", b = "b" }

but this is not correct. Here's what I see in nix-repl.

nix-repl> inputs.nixvim.lib.x86_64-linux.helpers.toLuaObject {__unkeyed.1 = "a"; b = "b";}
error: syntax error, unexpected FLOAT, expecting '.' or '='

       at «string»:1:62:

            1| inputs.nixvim.lib.x86_64-linux.helpers.toLuaObject {__unkeyed.1
             |                                                              ^

nix-repl> inputs.nixvim.lib.x86_64-linux.helpers.toLuaObject {__unkeyed1 = "a"; b = "b";}
"{ \"a\", b = \"b\" }"

nix-repl> inputs.nixvim.lib.x86_64-linux.helpers.toLuaObject {__unkeyed1 = "a"; __unkeyed2 = "b";}
"{ \"a\", \"b\" }"

nix-repl> inputs.nixvim.lib.x86_64-linux.helpers.toLuaObject {__unkeyed.a = "a"; b = "b";}
"{ { a = \"a\" }, b = \"b\" }"

I skimmed over this the first time I read. The comment should use quoted attr names, but other than that is is "correct". E.g. this will work: { "__unkeyed.1" = "foo"; }.

I can't recall if we normally use . or - separators elsewhere, but the toLua implementation just checks the key starts with __unkeyed.

[MattSturgeon]

Looking at the upstream docs: https://github.com/folke/which-key.nvim#%EF%B8%8F-mappings

The wording isn't concrete, but I get the impression the add() method is now preferred over the spec config option?

Either way I think the config option would still be a better fit for nixvim's module.

EDIT:

I also noticed other related issues still open. Some of these may be resolved already:

• #1167
• #1392

[MattSturgeon]

Another work-around until we provide a propper solution is to remove your plugins.which-key.registrations definition and instead call require('which-key').add with the new format.

I've done this in my config: MattSturgeon/nix-config@e0cb861

EDIT: You can now use plugins.which-key.settings.spec which I've updated my config to use here: MattSturgeon/nix-config@b1fcbde