Support description for keymaps and make them accessible

[LionC]

No description provided.

[Corey-Keller]

Do you have a high level picture on how you plan to implement this? I'm more than happy to try and implement this if you'd like, but I'd love to know if you have any particular ideas so that I don't do anything that is missing features or written 'incorrectly' (anything that'll result in 'tech debt' or end up requiring refactoring later on).

[LionC]

I am not sure myself yet - focussing on getting 1.1 out and planning to do this for 1.2. Some way to describe a keybind, which would also need to save it somewhere and then decide on some way (probably vim command + lua interface to get the raw data) to access those and display them in some default UI. Next step would be to connect those to telescope and which-key.

I do not have more plans yet - focussing on testing v1.1 right now when I have the time.

[LionC]

If you have an idea though - feel free! PRs are more than welcome :-)

[Corey-Keller]

For what it's worth, I've been using 1.1 exclusively for the last 2 weeks, and it has been perfectly stable. As far as I can tell there's nothing stopping 1.1 going stable immediately (if the description feature is indeed moving to 1.2 for planned release)

[LionC]

That is good to hear - thanks for the feedback! There is one issue open with three things to inspect before release, it sill probably ship as soon as I get to that. Maintenance is just limited to weekends right now, spending most time on my actual job and Deno contributions.

[Corey-Keller]

So I was thinking about how to do this, and my best idea is a table like this (the items in { } in the first one are the parameters you'd pass to nvim_set_keymap():

{
    {
        {mode} .. "_" .. {lhs} = {
            Target = "{rhs}",
            Description = "Some description",
        },
    },
    {
        -- using the `{ mode = 'i', {{ 'jk', '<Esc>' },` example from the readme
        i_jk = {
            Target = "<Esc>",
            Description = "jk exits insert mode",
        },
    },
}

I wanted to ensure that we've saved both the left AND right sides, so that you can use any of them to search by.

Do you have any thoughts on that? The questions I have so far are:

1. Is mode_lhs sufficiently unique enough for the lookup key, and will the special characters be an issue?
2. Any thoughts on any of the naming conventions?

[LionC]

I am not even sure if you need a new data format, you clould probably just save the "flattened" resolved config. That way you have access to everything and you do not need to migrate new options.

[Corey-Keller]

#17 adds 'support' for descriptions (right now it just doesn't do anything with the value, but it stores it if you put a string after the {rhs} in the mapping).

But it would be pretty trivial to add something like this for whichkey:

if vim.g.nest_whickey_integration then
    require("which-key").register({ [cfg.lhs] = { cfg.description } }, { mode = cfg.mode })
end

[Corey-Keller]

@LionC assuming you give #17 the go ahead, I can whip up a folke/which-key.nvim integration to close out #3 this afternoon. I just need to know how you want to do the checking. Do you want to do it with global variables like my comment above, or would you prefer a require('nest').setup() style method of handling the integrations?

[LionC]

Integrations should be in a subfolder in lua and only be loaded if the user explicitly calls a setup method to do so I think.

Thabks for your work! Just be aware that I will push 1.1 out before I can spend more time reviewing the post 1.1 festures like keymap descriptions and integrations.

[LionC]

Closed by #17