Implement an API to auto-load commands, autocmds, and keymaps from the nvim API

[mrjones2014]

Say you already have keymaps being set up another way, you just want them to be searchable with legendary.nvim.

We could load the commands, autocmds, and keymaps through the nvim APIs, as long as they have the desc key set.

Although I'm not sure how to do this effectively because right now, the API functions use the same table field definition for the description, or if no description is set, it's just the implementation, which we wouldn't wanna show as a description.

[mrjones2014]

Tried getting this unblocked by opening neovim/neovim#17639 but the response was basically just rude, toxic comments over and over basically saying "the description field isn't a description"...

[mrjones2014]

We may be able to do this for keymaps, but not commands. Keymaps have a separate desc field.

[danielo515]

I was about to open an issue to request this. Is this the same that telescope shows whith the built in commands selector?

[mrjones2014]

Yeah unfortunately there's not a great way to get descriptions and when I asked about it in the Neovim repo I was basically told "the description field isn't a description" 🤔

[danielo515]

Yeah unfortunately there's not a great way to get descriptions and when I asked about it in the Neovim repo I was basically told "the description field isn't a description" 🤔

what a ridiculous harsh answer. This is definetively a must have to compete with other mote friendly IDES. Do you plan to add it anyway? even without description?

[mrjones2014]

I'm not sure. It's something I've been thinking about a lot, but it doesn't really make sense to add items where the "description" is some long string of Lua code. The description field will be the description if one was set when defining it via the Neovim APIs, but if no description was set in the opts table, the desc field of the items returned from the API is just the Lua code or vim script string implementation of the keymap/command.

In those cases, it doesn't really make sense for Legendary to show that huge description string (it'll totally throw off formatting, not be useful, and look bad), and since the description field behaves like described above, there isn't really a way for legendary to tell whether items have an actual description, or if the description field is just the stringified implementation (Lua code or vim script string).

Here's the Neovim issue I opened about the topic if you want to take a look: neovim/neovim#17639

Perhaps it might be worth opening a new issue and hoping someone else responds.

[danielo515]

what about truncate the output to certain length and let the ugly stuff appear? Maybe behind a config flag. I can provide screenshot later, but this doesn't seem to be uncommon in the vim world, telescope and wich-key already do this.

[mrjones2014]

Maybe. Not sure. What happens when you have a custom description registered through legendary that exceeds that length, do we really want to cut that off? I'm not sure a simple max truncation length is the solution.

[danielo515]

What about implementing some basic heuristics to decide if the description is code or not? If it looks like a function call, it's preceded with Lua then a require etc then just don't display it? Just ideas

[mrjones2014]

Heuristics to decide if the description is code or not would be far from basic.

[LumenYoung]

Hi, I think it is also feasible to set a length limit to the description. And if the limit is exceeded, then the description field can be blank or "No description" or display the command itself. I think something like "[cmd itsef] (No description)" is reasonable enough.

The core problem here is that it is not possible to have automatically generated description for all commands. Therefore it might be wise to provide the command and let user to fill in the description themselves if it is necessary for them.

[mrjones2014]

So, looking again, it appears that keymaps now have a separate rhs vs. desc field, where the desc is actually a description. So it looks like it is now possible to do this for keymaps.

However the problem still exists for commands, where the definition field may be either an implementation or a description. I propose that this issue is split into two separate issues:

• Implement loading keymaps from Neovim API - which could be implemented with a PR
• Implement loading commands from Neovim API - which would remain blocked

[mrjones2014]

Closing this issue in favor of #258 (which could have a PR for it, if anyone wants to take a stab at it) and #259 (which remains blocked).