[Feature]: Load keymaps from Neovim API

[mrjones2014]

Similar Issues

• Before filing, I have searched for similar issues.

Description

Automatically load existing keymaps via vim.api.nvim_get_keymap(mode).

For additional context see #39

[mrjones2014]

If anyone wants to work on a PR here are some specific points I'd like to include in the implementation:

• Duplicate filtering -- don't register or apply keymaps that are already applied via legendary.nvim config
• Provide an API to load keymaps from the Neovim API, and also provide a boolean option in legendary.nvim config that loads them on require('legendary').setup()

[ehaynes99]

Heh, I was just coming to see if this had been filed before. I'm a little swamped right now, but might be able to look into in a few weeks.

This won't work in setup(), though. It would need to wait until called on a buffer, or it will be missing any mapping added after legendary setup was run. Personally, I don't set any keymaps until after all of the plugin configurations are complete, as I reference various plugins in the bindings (the lazy functions in toolbox attempt to work around this problem, but it's not an issue if you simply wait). This would also miss any dynamic bindings like those added by the lsp on_attach handlers. It could potentially cache the list by buffer id after the first time it's called for any particular buffer, but I'm not sure if anyone is doing even more dynamic mappings based on autocommands.

The telescope implementation of this does it on the fly every time without any noticeable delay.

[hinell]

The help index.txt is a good starting point I guess.

[mrjones2014]

@ehaynes99 I'd love to see a PR for this if you're still interested 🙂

[lougreenwood]

Just adding a note here that this seems to be the reason why neo-tree mappings (including opening and toggling neo tree) don't appear.

It seems that neo-tree uses nui to set it's mappings and nui uses vim.api.nvim_buf_set_keymap.

Not sure I have the skills or time to tackle this, but maybe I'll find the time if the pain gets high enough 😅 .

[mrjones2014]

Copying my comment from the linked issue here for documentation purposes:

Just jumping in here from the linked issue:

although it currently doesn't surface actual commands, see #39

You can define commands with legendary or load them into legendary, but it doesn't do it automatically for a few reasons. For commands coming from plugins, it should be pretty straightforward to write a legendary extension, there's a few bulit-in ones you can use as an example. They can be written in the upstream plugin repo, or as a PR to legendary itself.

@lougreenwood for example, neo-tree seems like it could have a legendary extension written for it, by mapping the action names from the neo-tree config to a description like

local descriptions = {
  navigate_up = 'Navigate up',
  order_by_git_status = 'Sort by git status',
  -- ... the rest here
}

And then converting the keymap definitions into the right format. Example: lazy.nvim legendary extension.

[lougreenwood]

Thanks @mrjones2014, however, it seems that if I were to try this, then effort spent creating a neo-tree extension would be better spent improving legendary so that it can import all mappings set using the vim api? WDYT?

[mrjones2014]

Yeah, at this point in time it should be possible to load keymaps from the vim.* API, however for some plugin mappings you might lose context doing it that way (for example, plugins like neo-tree that have mappings only in that specific buffer. some legendary extensions handle this based on filetype or buftype).

Loading commands, however, remains roadblocked (see the conversation in #39) because weirdly the desc field of the commands returned from the API is not reliably a description -- if no description was provided, the field will be the implementation of the command which could be a long ugly string of Lua or Vimscript code, which isn't really what we'd want to show in legendary.