bug: Custom registered mappings don't have the correct name

[MariaSolOs]

Did you check docs and existing issues?

• I have read all the which-key.nvim docs
• I have searched the existing issues of which-key.nvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

v0.10.0-dev-673+g622ae2f53

Operating system/version

Mac Ventura 13.4.1

Describe the bug

Starting from version >= 1.5.0, mappings that I register using a custom name are displayed using +prefix instead of the name I configured.

Steps To Reproduce

Register a group of commands that have a common prefix and register a name for which-key to use.

For example, I register this set of rust commands when loading rust-tools:

But which-key shows +prefix instead of +rust when pressing <leader>R:

Interestingly enough, the prefix does appear once I press R:

Expected Behavior

For which-key to always show the name I configured.

[MariaSolOs]

Okay I debugged this a bit and removing this line fixes it. For some reason in this call the group has a name but children is empty, while here there are children but the name is gone. An easy fix would be to modify the if condition accordingly, but I'm not sure if the described behaviour is the expected design or another bug :/

[abeldekat]

This occurs starting with commit 8503c0d:
fix(keys): don't show empty groups

The commit came shortly after discussing this issue with @folke : empty group names

I see the same problem in LazyVim in the git submenu. This contains the "h" for the "hunks" submenu, labeled "prefix".
I expected to solve this using the following code in lua.lazyvim.plugins.editor:

--- fragment of gitsigns setup:
config = function(_, opts)      
     require("gitsigns").setup(opts)
     require("lazyvim.util").on_load("which-key.nvim", function()
         require("which-key").register({ mode = { "n", "v" }, ["<leader>gh"] = { name = "+hunks" } })
       end)
end

No luck, unfortunately. The "h" is still labeled prefix, all inner menu items are present.

My knowledge of the which-key code is very limited. Given this limitation, my suggestion would be:

Do show empty group names, as the user configures a group name with intent. The group name unexpectedly being empty shows a mismatch between the intent of the user and the actual code...

[ckt114]

This bug seems to be in v1.5.0+ only. Tested with v1.4.0 and it’s working as expected.

[Keep-Simple]

+1

[HIDE-r]

+1

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.