FR: an option that allows users to have their mappings automatically registered with which-key

[einalex]

Hiya!
After looking at which-key, legendary and command_center, it is very clear to me, that your config format is the most elegant one.

If users can one day easily feed their which-key plugin from their command_center config, the most user friendly configuration of keymaps and command reminders has been achieved.
Seems like a good plan to me :)

[Feiyou Guo]

I am glad you love it!

I was working on making command_center support/accept which-key and legendary's syntax, but not vice versa. However, this sounds like an even better idea. I will definitely put it on the roadmap.

[tobinstultiens]

I'm curious if there has been any progress on this implementation?
In the meantime I created a function that can use your CommanderItem to add the description to vim which can be read by which-key.

-- Function to check if an array contains an object with a certain key pair if the array is non-empty
local function containsObjectWithKey(arr, key)
  if arr == nil then
    return false
  end
  for _, obj in ipairs(arr) do
    if obj[key] ~= nil then
      return true
    end
  end
  return false
end

-- Set description of object defined for commander using the CommanderItem
local function setDescription (item)
  if item.keys == nil then
    return
  end
  if containsObjectWithKey(item.keys[3], "noremap") and containsObjectWithKey(item.keys[3], "silent") then
    vim.keymap.set(item.keys[1], item.keys[2], item.cmd, {desc = item.desc, noremap = item.keys[3].noremap, silent = item.keys[3].silent})
  elseif containsObjectWithKey(item.keys[3], "noremap") then
    vim.keymap.set(item.keys[1], item.keys[2], item.cmd, {desc = item.desc, noremap = item.keys[3].noremap})
  elseif containsObjectWithKey(item.keys[3], "silent") then
    vim.keymap.set(item.keys[1], item.keys[2], item.cmd, {desc = item.desc, silent = item.keys[3].silent})
  else
    vim.keymap.set(item.keys[1], item.keys[2], item.cmd, {desc = item.desc})
  end
end

local commanderKeymapList = {} -- Add all the commands to this mapping.

-- This will convert all added commands to commander to also be descriptive for which-key
for _, obj in ipairs(commanderKeymapList) do
  setDescription(obj)
end

[Feiyou Guo]

@tobinstultiens, @einalex
Just so you know, Commander sets up keymaps through vim.keymap.set natively since neovim 0.7. So I believe which-key can automatically pick up desc field without any further setup.

[tobinstultiens]

Sadly on my setup this does not work @FeiyouG .
This is done using only commander nvim for setting up the keybinds


With my setDescription helper:

So most likely there is a weird bug with the setting of the keymap. (Might be a race condition for which-key).

[XobSod]

Yea, I also had this working in "before" version, but after upgrading Which-key lost all descriptions... I didn't have time to troubleshoot this so I reverted to "before" version.

[tobinstultiens]

Do you know the version @XobSod? Then I can maybe check what is the cause.

[XobSod]

Sorry @tobinstultiens i missed your message.
Currently I am on commit 0d820c438c871fe31ed942bc592a070da1564141, and which-key picks up bindings correctly:

but when I switched to master, rewrote configs which-key lost the descriptions... I didn't spent much time on this, maybe this was my fault, not understanding how to add descriptions in the new config format... I just reverted back to the above commit.

[Feiyou Guo]

@tobinstultiens @XobSod I don't use which-key myself and haven't dug around it's code base. But I am wondering will declaring commander as a dependency for which key help, since it guarantees that key maps are set before which-key is loaded?

[tobinstultiens]

By looking into it I know that the refactor to Commander 0.2 changed something that causes which-key to no longer be able to find the registered descriptions. Since by reverting to the commit before this change as shared by @XobSod and implementing it as described then does allow which-key to read the descriptions.

I'm currently looking into what change is behind this issue but I wanted to at least share my findings. Since I'll only be able to look into it every once in a while when I get time.