Open Julpikar opened 3 years ago
The telescope plugin ( https://github.com/nvim-telescope/telescope.nvim ) already has something like this, you can find a function called keymaps
that shows existing key bindings in a popup window
@smartding thank you for your answer, Telescope is a great plugin. But when I tried keymaps function from this Telescope plugin, I needed to press more than 3 keyboard buttons to execute a command. It more complicated than what vim-which-key and vim-leader-guide can do.
I am planning to create something after the the keymaps PR lands. The idea is basically in the PR, but wrong/invalid keybindings and settings are currently hard to track.
@matu3ba Thank for your info. I have tried to modifed existing plugin to work with lua, but nothing is worked as I expected. I thought this type plugin should be written using Lua from scratch.
fyi: I just released a Lua port of which-key.
Let me know what you think!
timeoutlen=0
)motions
, text-objects
, operators
, windows
, nav
, z
and g
@folke that's brilliant! Thanks for all the great plugins lately.
@disrupted thank you! Having a lot of fun with Lua 😅
I've also recently released a plugin legendary.nvim which has an integration with @folke's which-key.nvim
, but also handles commands and autocmds, and makes everything searchable via vim.ui.select()
.
augroup
/autocmd
s as simple Lua tables, then bind them with legendary.nvim
which-key.nvim
tables with legendary.nvim
vim.ui.select()
so it can be hooked up to a fuzzy finder using something like dressing.nvim for a VS Code command palette like interfaceI am wondering if there is an automatic solution. I mean whichkey require that you configure to any mapping a description but in neovim this is not standard so you need to do it manually for all the hotkeys and is very time consuming. This is the reason why I am not doing this plugins and I have paper notes to speed up. Maybe create a repository of mappings with descriptions of all those plugins to simplify can be another idea, like a crowdfounding for mappings description.
@Mte90 not entirely sure what you mean? With these plugins, you add the description in the same place you create the keymap itself. legendary.nvim
also provides descriptions for a big set of built-in keymaps and commands.
@Mte90 not entirely sure what you mean? With these plugins, you add the description in the same place you create the keymap itself.
legendary.nvim
also provides descriptions for a big set of built-in keymaps and commands.
basically I have to do in my settings a description for any mapping I have, so also for plugins mappings. You have to do it maybe for the same plugins mappings, another user too etc. This means a duplication of code that can be released by a specific plugin as example that contain the description for the mappings of various plugins, in this way it is more simple to use this solution also for newcomers as they don't have to code just to set a description.
Ah. I'm looking at a way to load keymaps and commands via vim.api.nvim_get_keymap
and vim.api.nvim_get_commands
, but the issue I'm running into is, the API uses the same field (definition
) for the description, if there is one, or the implementation if there isn't one.
It's not very useful for my plugin to show a bunch of Lua code as the description so I'd need a way to filter out items that don't have a real description. See: https://github.com/mrjones2014/legendary.nvim/issues/39
See also https://github.com/linty-org/key-menu.nvim and in special https://github.com/linty-org/key-menu.nvim/issues/10 if you want to see support for builtin commands.
The proper fix would require to deviate from Vim, as it looks like Bram does not accept patches https://github.com/vim/vim/issues/10503.
What? A plugin that can help remember or show existing keybindings that written in lua.
Why? There are existing viml based plugin like vim-which-key and vim-leader-guide but hard to setting if your configuration is lua based. Main problem I have found is existing plugin using viml dictionary that can be hard to translate to lua. Another reason we need this new plugin is the existing implementation have less configuration in user interface. I hope new implementation have better looking than existing plugin.