plugin: BotCommandScope builder

[KnorpelSenf]

Create a new repo with a plugin for advanced command filtering that goes beyond what people usually need. This not only allows users to do cooler things, but it also helps the core package stay focused on other things.

Desired features:

• should work like menu plugin, but for command filtering
• argument matching
• ctx.command property that exposes the invoked command on the context object (useful for what we currently do with bot.command(array) where it is not possible to find out which command was invoked without inspecting the message text)
• custom command prefixes, such as ! instead of /
• optional case insensitivity
• plugin should have the name commands

[EdJoPaTo]

It might be interesting to export the commands to setMyCommands.
Not sure if that's easily possible as they also require a description.

Some kind of check would be great to ensure only commands are set which are actually implemented in the bot.

[KnorpelSenf]

I was thinking to have a method syncCommands which internally calls setMyCommands with all the right scopes set. That would be the point of the command builder, to unify setting the commands and registering listeners for them. This is analogous to the menu plugin in the way that the latter combines building inline keyboard buttons and handlers, and the commands plugin would combine defining commands and their handlers.

[andrrms]

If I well undestood, this can use the following syntax...?

bot.command
    .name("start")
    .description("Welcomes first-time users")
    .filter(/* Do filtering stuff */)
    .defaultDo((ctx) => { /* Everyone */ })
    .onPrivateChat((ctx) => { /* Only on PM */ })
    .onGroupAdmins((ctx) => { /* Only group admins */ })

[KnorpelSenf]

I do not have a concrete plan for this yet. You're more than welcome to make suggestions!

Telegram often has matching concepts that are at different places in the API, where it is convenient to bring things together. Inline keyboards are sent, and callback queries are received. The menu plugin brings this together by letting you define handlers directly alongside your inline keyboard.

The commands plugin could bring together two other things, namely setting command scopes and handling command messages. That's as far as I have planned, the rest are good ideas that may or may not fit into the cohesive vision that we need for this plugin.

[dcdunkan]

Feature suggestion: "Did you mean ...?" for misspelled commands. It could also have a configurable error-help message like we usually see when subcommands are misspelled in CLI applications.

[waptik]

I was thinking to have a method syncCommands which internally calls setMyCommands with all the right scopes set. That would be the point of the command builder, to unify setting the commands and registering listeners for them. This is analogous to the menu plugin in the way that the latter combines building inline keyboard buttons and handlers, and the commands plugin would combine defining commands and their handlers.

I think the syncCommands is a good one and it should be called automagically when the command builder is initialized. Also the builder should have a way to define whether a command should be part of syncCommands or not.
Sometimes, you just want to have commands that you don't want users of the bot to be aware of but are publicly available like how you only add manually these public commands in setMyCommands atm.

[KnorpelSenf]

Feature suggestion: "Did you mean ...?"

We could compute the Levenshtein distance to all registered commands, and provide ctx.nearestCommand if an unknown command was sent. Alternatively, we could have a separate otherwise handler that gets called with the nearest command if an unknown command was sent.