Improvement for plugin listing: separate "important plugins" from the rest

[henk84]

I recently tried to find a command to restart the bot and found it to be cognitively demanding to navigate the list output, independently of my concrete endeavour.

It returns a list of (in my case) 51 words, ordered alphabetically, which I have to parse to find potential candidates which might contain a command suitable for what I wanted to do.
That’s a lot of mental processing to do.
The alternative would have been to guess on which words could be used for what I want to do and "brute-force" whether that command exists. Also quite the load.

So in order to reduce that load, I think it would be great if the list could be split up in easier to process categories with fewer items. Ideally each category of plugins or commands would contain somewhere around 10-15 items, I’d think.

I already talked about this on IRC and the concept of "important plugins" was mentioned.
In a first step it would be great if those could be separated in the output of list.

Hopefully when the basic mechanism for categorizing is implemented, the remaining plugins can be categorized as is already the case on https://limnoria.net/plugins.xhtml.

Ideally there would also be expanded functionality on the list command, as in

• list categories shows the existing plugin categories
• list category XY shows plugins in category XY
• list plugins shows all plugins
• list plugin YZ shows commands in plugin YZ
• list commands lists all commands

Writing this now my suggestions seem to be at odds with how things are currently done … I’m not sure I understand the concept of which command does what, in particular regarding commands, command, plugins, plugin, list, etc. but I’m not trying to make concrete suggestions on what commands should be used, just on what functionality I would like to see.

Thank for your consideration and your effort!

[jlu5]

FWIW, I recently rewrote the Getting Started guide to better explain how the plugin / command hierarchy works. We actually have a command for searching for commands by name already: apropos <string>, but ironically it's quite hard to find. We might rename it to commandsearch in a later release.