Skip to content

[DISCUSSION]: Aliases for slash commands? #2554

Closed

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.

Activity

  1. Lulalaby commented on Aug 19, 2024

    @Lulalaby
    Member

    Waiting.gif

  2. Paillat-dev commented on Aug 19, 2024

    @Paillat-dev
    MemberAuthor

    there we go lmao

  3. Lulalaby commented on Aug 19, 2024

    @Lulalaby
    Member

    ea7Us5SaB_yhOfYxebFbAugsDXo.gif

    Wall of text

  4. changed the title [-][DISCUSSION]: Aliases for slash command?[/-] [+][DISCUSSION]: Aliases for slash commands?[/+] on Aug 19, 2024
  5. plun1331 commented on Aug 19, 2024

    @plun1331
    Member

    i feel like GitHub has a feature designed specifically for discussions that we could be using

  6. Paillat-dev commented on Aug 19, 2024

    @Paillat-dev
    MemberAuthor

    Can someone with perms do the move to discussion thing then?

  7. JustaSqu1d commented on Aug 19, 2024

    @JustaSqu1d
    Member

    I propose the exact wording for the second option to be " (i.e., , , ...)"

  8. Paillat-dev commented on Aug 19, 2024

    @Paillat-dev
    MemberAuthor

    github removed it but he said "<command description> (i.e., <alias1>, <alias2>, ...)"

  9. locked and limited conversation to collaborators on Aug 19, 2024
  10. converted this issue into a discussion #2557 on Aug 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions