Expose DEFAULT_KEYMAPS And Current Mappings

[hinell]

I requet to export default keymapping to ensure stable api .e.g.:

local   keymaps = require("nvim-tree").DEFAULT_KEYMAPS
...

Can this functionality be implemented utilising API?

• Well, it can, but the following is not guaranteed to be stable:
  

require("nvim-tree.keymap").keymaps

Note The callbacks should be exported explicitly!

[mrjones2014]

Copying my comment here in case you are interested in helping me figure out how an implementation would work with an upstream plugin: mrjones2014/legendary.nvim#289 (comment)

Hey there, this is awesome, thanks for filing the issue!

This may be better suited actually for #184, nvim-tree is probably a good candidate for a first one for a proof of concept.

I'm not sure exactly what they will look like, but I have a few ideas. The best idea I have currently is along the lines of:

Legendary.nvim must be loaded before other plugins. We have a set of plugins, or plugins can be provided by the other plugin itself, at legendary.plugins.[plugin name]. This way, plugins can be looked up dynamically; that is, if they wanted to, nvim-tree could provide its own legendary.nvim integration by adding lua/legendary/plugins/nvim_tree.lua in their repo, just for an example.

The plugin is just a plugin-specific script that must handle registering its keymaps, commands, autocmds, and functions. It may set up autocmds to do so on BufEnter for example, or it may call some custom logic to determine the correct buffer to attach to.

So for this example, and nvim-tree / legendary.nvim plugin would look like:

User's config:

require('legendary').setup({
  plugins = {
    nvim_tree = true,
  }
})

File: lua/legendary/plugins/nvim_tree.lua

vim.api.nvim_create_autocmd('FileType', {
  pattern = 'NvimTree',
  once = true,
  callback = function()
        local   nvimtreemappings = require("nvim-tree.keymap").keymaps
        local   keystodisable    = vim.tbl_map(function(e) return e.key end, nvimtreemappings)
        -- Set up Legendary plugin keybindigns
        local keymaps = vim.tbl_map(function(e)
            -- just set up a description-only keymap
            local entry = {}
            entry.mode  = "n"
            entry[1]    = e.key        -- Key
            if type(e.key) == "table" then entry[1] = e.key[1] end
            entry.description = "Nvim-tree: " .. e.desc
            entry.opts = { buffer = bufnr, noremap = true }
            return entry
        end, nvimtreemappings)
        require('legendary').keymaps(keymaps)
  end
})

[hinell]

@mrjones2014 No need for a copy. Replied in the original issue/thread.

[mrjones2014]

Yeah I meant if nvim-tree would be interested in having the plugin in this repo

[alex-courtis]

Copying my comment here in case you are interested in helping me figure out how an implementation would work with an upstream plugin: mrjones2014/legendary.nvim#289 (comment)

Left some notes about on_attach callback and future direction of mappings: mrjones2014/legendary.nvim#289 (comment)

Yeah I meant if nvim-tree would be interested in having the plugin in this repo

I'm not quite sure exactly what you mean but we are always open to new ideas.

Well, it can, but the following is not guaranteed to be stable:

Mappings are considered to be API and will never change, only be added to. :help nvim-tree-default-mappings is a source of truth: it is always updated with DEFAULT_MAPPINGS.

Is that enough, considering the future in which view.mapping will be deprecated in favour of an on_attach callback where you have full control, with all mappings invoking public API?

[mrjones2014]

Basically what we would need on the legendary.nvim side is a way to access an up-to-date list of the keymaps (including/considering user config of nvim-tree) with descriptions.

That sounds like what require("nvim-tree.keymap").keymaps is, is that correct?

So a legendary.nvim / nvim-tree plugin integration would look like legendary.nvim wrapping the on_attach function, calling the users' first, then calling our own to peek at the keymaps the user may have set.

[alex-courtis]

That would work nicely: we have a solution for now and a solution for the future.

Let's let the DEFAULT_KEYMAPS keymaps out via API. Create a deep copy of DEFAULT_KEYMAPS instead of returning the actual defaults.

We can also expose the current keymaps in the same manner. Not sure of a use case, but costs little.

We could expose the current mappings for modification however setting up the callbacks would be tricky. Would require a valid use case.

[mrjones2014]

We can also expose the current keymaps in the same manner.

I think this is all that would be needed. These would be set after the user's on_attach, correct? So we could wrap that function to get their configured keymaps.

[alex-courtis]

I think this is all that would be needed. These would be set after the user's on_attach, correct? So we could wrap that function to get their configured keymaps.

That would work nicely. You can enumerate all their mappings for the buffer.

One difficulty might be identifying which mappings are nvim-tree specific. A convention approach may be necessary via, say, a prefix in the description. That will be available for the default mappings.

[mrjones2014]

Couldn’t I use require("nvim-tree.keymap").keymaps?

One other thing is actually hooking into on_attach because if the user config loads after our plugin, they’d overwrite our on_attach. Could you possibly do a doautocmd User NvimTreeAttached that we could hook into?

[alex-courtis]

Couldn’t I use require("nvim-tree.keymap").keymaps?

Yes, however that is not API and may be subject to change e.g. refactor.

We will add API for future reliability.

One other thing is actually hooking into on_attach because if the user config loads after our plugin, they’d overwrite our on_attach. Could you possibly do a doautocmd User NvimTreeAttached that we could hook into?

That's really interesting... please elaborate on how that will work.

Adding an event is a possibility :help nvim-tree-event