Type of feature request

Command

Description of the feature you're suggesting

When users are instructed to set an API key with [p]set api, they are often told to fill in parts of the command by marking a part with something like <keyname> (for example, [p]set api youtube api_key <your_api_key_here>). When this is done, the user is expected to replace the entire word, including the <>s. Sometimes users do not realize this, and enter their key within <>s. This often breaks the API service in an unexpected way, which can be confusing for users.

We can't reject keys that are wrapped in <>s, because they may be valid for a strange service out there, however we should warn the user to double check if their key is actually supposed to be formatted like that. All secrets should be checked to see if they start with < and end with >, and if so the user should be warned that they may have failed to replace the entire block, with a warning added to the confirmation message such as:

You may have failed to properly format the key. If you were told to enter a key with an example such as [p]set api youtube api_key <your_api_key_here>, and your API key was HREDFGWE, make sure to run [p]set api youtube api_key HREDFGWE, and not [p]set api youtube api_key <HREDFGWE>

There's a small concern that a key might be something entirely stupid like <> itself, and this would technically reveal information about the key, but I believe that is a relatively tiny concern.

Anything else?

No response