Skip to content

[DISCUSSION]: Aliases for slash commands? #2554

Description

@Paillat-dev

Feature

Having slash command aliases, meaning you can use multiple names for one slash command

Rationale

Multiple users have been asking about this, in the official server, as well as in other places. In my opinion, it feels weird for the end user no to have the possibility to use aliases= in slash commands. Notably, when switching to slash commands from prefixed, it is one lost feature, and NOT ONLY for the library user, but also for the related bot's end user, as their shortcuts and muscle memory will be lost in slash commands. Sometimes, aliases not only allow shorthand, but also completely different command names, and in both cases, autocompletion is not always enough.

This would also allow for bette compatibility between slash and prefix with bridge (which is also being partially rewritten afaik) as the alias parameter would not be ignored by slash commands. This would feel more intuitive in my opinion.

I am a strong defender of slash commands, and often only use them, however, I myself feel like this feature is missing sometimes as well.

Implementation

Here are, after discussing with others, possible implementations, which are not exhaustive:

  1. Literally duplication slash commands: this would create multiple identical slash commands (with the same callback) and a different name. It is nowhere the ideal solution, nor my favourite, but mention it nonetheless. While it would be the most ideal and intuitive solution, it would probably flood the slash command menu, and create unnecessary complexity for the end user.

  2. Leveraging the command description autocomplete: This would insert the different aliases at the end of the slash command's description (i.e. ",".join(aliases)). Since discord uses the command description for the autocompletion of the slash command menu, it would technically work, and the use would (most often) be proposed with the correct command for a given alias. It is less direct and "logical" than the first proposition, but doesn't have its downsides either, and is a good compromise in my opinion

  3. Both?: This would literally be to give the use the choice for "real" and "fake" aliases and is more a troll proposition than anything imo but I put it anyways.

Challenges

Challenges not to overlook are the following

  1. For option 2, there is a description max length.
  2. Command groups might cause some problems
  3. Documentation, this would need to be clearly documented, so that users clearly understand what is being done under the hood, who, and why,
  4. Anything else? For sure, but couldn't think of it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions