[mini.clue] How to get all conflicting mappings?

[ahmedelgabri]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.clue

Question

I found out that I have some conflicting mappings and I was wondering if mini.clue can help me with this?

[echasnovski]

Would you mind elaborating what do you mean by "conflicting mappings"? Preferably with some examples.

If you create mappings in the same mode and the same left hand side (like <Leader>ff, for example), then it is "the last created wins" kind of situation and 'mini.clue' can know only about that.

[ahmedelgabri]

Would you mind elaborating what do you mean by "conflicting mappings"? Preferably with some examples.

I had two mappings similar to this

• <leader>f
• <leader>fx, <leader>fy, etc…

So when I did <leader>f it was a bit slow, because I assume neovim was waiting for the next character which can also trigger something else. I'd like to avoid this. Because clue will only show either a single mapping f or the mappings for f* as a group.

If you create mappings in the same mode and the same left hand side (like ff, for example), then it is "the last created wins" kind of situation and 'mini.clue' can know only about that.

Makes sense, any idea how to get this info (if possible) from Neovim itself?

[echasnovski]

I had two mappings similar to this

* `<leader>f`

* `<leader>fx`, `<leader>fy`, etc…

So when I did <leader>f it was a bit slow, because I assume neovim was waiting for the next character which can also trigger something else. I'd like to avoid this. Because clue will only show either a single mapping f or the mappings for f* as a group.

Aha, this kind of "conflicting". The 'mini.clue' can help here in the following sense:

• If <Leader> is defined as trigger, then after pressing it 'mini.clue' will start its own key query process. With defaults, it means that window with clues will be shown after one second (can be adjusted with config.window.delay).
• In the clue window for the <Leader> key it will then show that f is a "group key" (highlighted with MiniClueDescGroup highlight group but has a description of <Leader>f mapping (if provided during its creation). Usually you'd want to have custom clues for those groups, like this.
• Pressing f will then show (immediately if the window was already visible) all the x / y / etc. keys that can be pressed for all other present mappings. You can still execute <Leader>f by pressing <CR> at this point. It will then close the window and will act as if <Leader>f is pressed without 'mini.clue' (i.e. wait for 'timeoutlen' milliseconds for extra keys and then execute its mapping).

So in a sense 'mini.clue' is helpful here because it always prefers description from existing mappings over the clues provided by the user. This can be used to spot the conflicts.

If you create mappings in the same mode and the same left hand side (like ff, for example), then it is "the last created wins" kind of situation and 'mini.clue' can know only about that.

Makes sense, any idea how to get this info (if possible) from Neovim itself?

For those kind of conflicts (which are different from the ones you describe) Neovim itself only knows about the last one.
For "prefix like" conflict, you can execute :nmap <Leader>f and it will show all Normal mode mappings that start with <Leader>f. You can then inspect it for conflicts manually.

Hope it helps.

[ahmedelgabri]

Aha, this kind of "conflicting". The 'mini.clue' can help here in the following sense:

• If <Leader> is defined as trigger, then after pressing it 'mini.clue' will start its own key query process. With defaults, it means that window with clues will be shown after one second (can be adjusted with config.window.delay).

• In the clue window for the <Leader> key it will then show that f is a "group key" (highlighted with MiniClueDescGroup highlight group but has a description of <Leader>f mapping (if provided during its creation). Usually you'd want to have custom clues for those groups, like this.

• Pressing f will then show (immediately if the window was already visible) all the x / y / etc. keys that can be pressed for all other present mappings. You can still execute <Leader>f by pressing <CR> at this point. It will then close the window and will act as if <Leader>f is pressed without 'mini.clue' (i.e. wait for 'timeoutlen' milliseconds for extra keys and then execute its mapping).

So in a sense 'mini.clue' is helpful here because it always prefers description from existing mappings over the clues provided by the user. This can be used to spot the conflicts.

Yeah, I'm aware of this. I was hoping for something more programmatically if possible. Thanks anyway.