Rework command system to add context command and autocomplete support

[Tais993]

Is your feature request related to a problem? Please describe.
Discord has added a lot of things, and to use those, we need to update our command system to reflect these changes.

Describe the solution you'd like

Initial proposal

Context commands:

We add BotCommand which extends the UserInteractor added with b9b047a
This interface gets getType, getVisibility and getData.

After that we'll add a MessageContextInteraction and UserContextInteraction interface (for the context menus)
Those 2 and SlashCommand will all implement the BotCommand interface.

Now we will rename SlashCommandVisibility to CommandVisibility

Note, SlashCommand will return SlashCommandData instead of CommandData for the getData method

There will probably also come an abstract class like SlashCommand has for context-command's, but will see that when I go deeper into our system

Autocomplete:

JDA added OptionData#setAutoComplete(boolean). If autocomplete is set to true, Discord will send autocomplete interactions.
Thus, we add onCommandAutoCompleteInteractionEvent(CommandAutoCompleteInteractionEvent) to the SlashCommand
The command has to filter for which option the event is, our command-system will filter for which command.

To-do

• Rename SlashCommandVisibility to CommandVisibility a0fb71e
• Move getType, getVisibility and getData to BotCommand a0fb71e
• Move component ID logic documentation into acceptComponentIdGenerator a0fb71e
• Add BotCommandAdapter (and move some SlashCommandAdapter method to there) a0fb71e
• Add ContextCommandAdapter (for the differentation between Message and User context commands)
• Add MessageContextInteraction + UserContextInteraction a0fb71e
• Update BotCore
• Add onAutoComplete to SlashCommand and SlashCommandAdapter a0fb71e
• Update all documentation
• Add support for multiple commands of different types with the same name
• Automatically update commands on start-up (and remove the reload command) e3aa80b
• Update SlashCommandProvider to become a general CommandProvider e3aa80b

Future:

• Update JDA
• onModal method

[Tais993]

If we agree, I'll work on this with love :p

[marko-radosavljevic]

Me likes autocomplete very much, so you have my unwavering support. 🥰

Now, don't know what 'context command' is, but I see interfaces, and interfaces are good, so I guess I like that too. I'm a bit suspicious that you bundled these two together, tho. Feels like a Trojan horse, you know, since everyone loves autocomplete... 🤔

[Tais993]

Context menu's are commands you receive when you right click an user / message.

[Budbomber]

Auto complete could come in extremely handy in a lot of use cases, and I guess like Marko said interfaces makes it better

[Zabuzard]

Im all in for the autocomplete and im also all in for context menus. But I dont quite get why context menus and slash commands are put together. Like, I am not sure why you proposed your design in the way you proposed it.

So from my side: green light on adding those features.
But orange light for the design.

That said, feel free to get started and once I am more familiar with whats going on, I might propose something different. Or you elaborate a bit on how things work and your reasoning and maybe I can give my 2cents then earlier already.

[Tais993]

But I dont quite get why context menus and slash commands are put together. Like, I am not sure why you proposed your design in the way you proposed it.

Within Discord's design context-commands and slash-commands are within the same hierarchy, thus I "copied" their design.
If you find it odd, I could change it without issues. I'd still keep the ComponentUser interface though, I'm fine with removing a general "command" interface, and just going for ContextCommand and SlashCommand separately
And for the fun, I've a quote from one of Discord's developers :p

our goal was to get something out quickly

[Zabuzard]

Within Discord's design context-commands and slash-commands are within the same hierarchy, thus I "copied" their design.

I see.

If you find it odd, I could change it without issues.

Our SlashCommand design has been born without thinking a lot into the future regarding what else we might need (regular commands, context commands, ...), mostly also because it is just impossible to think that much ahead.

That said, if it makes sense to change existing design for new stuff, it is totally reasonable to do so. In general, it might maybe make sense to first create the new context commands by copy-pasta and then we see which parts are identical and which not and can unify them nicely.

We just have to be aware that in the future there might be another XY-Command thingy coming our way that we want to unify into the system... so as much as it makes sense to merge things together, we also have to be flexible enough to support extra logic at some point.

tldr: Your plan sounds reasonable, go ahead. But be prepared that we will probably change design a bit once we all have a clearer picture on the concrete code.

[Tais993]

Will make 2 separate designs, and take a look at mixing them together in the end then ^^

[Tais993]

When finished, I'll create a draft PR to the JDA5 branch.

This way the command-system can be viewed without having all changes from the JDA5 branch too.

Once JDA5 is merged, we'll change the target for sure, but this allows us to take a look at the system before hand

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label, comment or add the valid label or this will be closed in 5 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label, comment or add the valid label or this will be closed in 5 days.

[Tais993]