You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Message and User commands aren't the easiest to use - they require users to know they exist in the first place, and even then are hidden behind a context menu, which makes them difficult for power users to use efficiently.
Describe the solution you'd like
Allow message commands to be executed by sending prefix command_name Convertable<Message> or by sending prefix command_name while replying to a message. The first executes the message command named command_name on the message referenced by the argument, and the second executes the message command command_name on the message that was replied to.
Similarly for user commands, they can be executed by sending prefix command_name Convertable<User>.
Additional context
This would be a breaking change as MessageContext and UserContext would have to be changed to no longer always include an interaction.
These options for executing message and user commands would not be registered as text slash commands as, if going through the slash command interface, users can simply use the existing context menu.
Questions to answer:
How is command_name determined? The names of user and message commands can include spaces, but this wouldn't work very well for command prefixes. Maybe we can allow both spaced and snake_cased command names?
Could we also allow sending prefix command_name while replying to a message to run a user command on the user that sent the message? If so, how do we handle messages sent by webhooks with no user attached?
The text was updated successfully, but these errors were encountered:
I'll go forward by setting command_name using the convertToKebabCase function already used for argument names, and I think we will disallow running user commands by replying as it is unintuitive.
Is your feature request related to a problem? Please describe.
Message and User commands aren't the easiest to use - they require users to know they exist in the first place, and even then are hidden behind a context menu, which makes them difficult for power users to use efficiently.
Describe the solution you'd like
Allow message commands to be executed by sending
prefix command_name Convertable<Message>
or by sendingprefix command_name
while replying to a message. The first executes the message command namedcommand_name
on the message referenced by the argument, and the second executes the message commandcommand_name
on the message that was replied to.Similarly for user commands, they can be executed by sending
prefix command_name Convertable<User>
.Additional context
This would be a breaking change as
MessageContext
andUserContext
would have to be changed to no longer always include an interaction.These options for executing message and user commands would not be registered as text slash commands as, if going through the slash command interface, users can simply use the existing context menu.
Questions to answer:
command_name
determined? The names of user and message commands can include spaces, but this wouldn't work very well for command prefixes. Maybe we can allow both spaced and snake_cased command names?prefix command_name
while replying to a message to run a user command on the user that sent the message? If so, how do we handle messages sent by webhooks with no user attached?The text was updated successfully, but these errors were encountered: