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
{{ message }}
This repository has been archived by the owner on Dec 24, 2021. It is now read-only.
Is your feature request related to a problem? Please describe.
Say you want to create an argument type, which contains spaces, such as 2h 43m or anything else that contains spaces and is of a well-defined consumable format. Currently there's no way for an ArgumentType to get arguments with spaces, except if the user manually specified the argument to be able to contain spaces by surrounding it by quotes.
While the quote way makes sense for people used to commands in the shell, I feel the way to have a consume function which can deduce how much of the argument string belongs to it would enable bot makers to create more user-friendly commands by not requiring the users to wrap stuff in quotes if it's possible to parse the argument string without doing so.
Describe the solution you'd like
ArgumentTypes would get an optional consume function which gets the unconsumed portion of the argument string, the message and the argument object that uses the type (similar to how parse and validate works). It will return how many characters it would like to consume. When the function returns, the argument string gets split at the index returned and the rest of the string continues to be parsed, and passed into the next consume function, until all arguments have been parsed.
Describe alternatives you've considered
An alternative would be to enable regex-matching for arguments, but that's less powerful than a consume function. If you want regex matching you can still do that from within the consume function
Additional context
I'd be willing on working on this feature if it's desired, but I don't want to work on it if the maintainers oppose the idea as a whole.
A nifty side-effect of using consume is that you can now create commands using an argument setup like this; [arg1], [arg2], [arg3]
rather than this; [arg1, [arg2, [arg3]]]
which is the only current way to implement optional arguments. This could be achieved by consuming 0 characters, handing over the entire, unmodified argument string to the next argument in the list.
The text was updated successfully, but these errors were encountered:
This feature will definitely help me make my code cleaner. Instead of making the last parameter (which, actually, contains a few parameters within it) string and parsing it to obtain the parameters I want to get out of it, I'll finally just make a few custom argument types that will let me change only one parameter, in the case If I want to allow users pass the arguments in other formats.
Is your feature request related to a problem? Please describe.
Say you want to create an argument type, which contains spaces, such as
2h 43m
or anything else that contains spaces and is of a well-defined consumable format. Currently there's no way for an ArgumentType to get arguments with spaces, except if the user manually specified the argument to be able to contain spaces by surrounding it by quotes.While the quote way makes sense for people used to commands in the shell, I feel the way to have a consume function which can deduce how much of the argument string belongs to it would enable bot makers to create more user-friendly commands by not requiring the users to wrap stuff in quotes if it's possible to parse the argument string without doing so.
Describe the solution you'd like
ArgumentTypes would get an optional
consume
function which gets the unconsumed portion of the argument string, the message and the argument object that uses the type (similar to how parse and validate works). It will return how many characters it would like to consume. When the function returns, the argument string gets split at the index returned and the rest of the string continues to be parsed, and passed into the next consume function, until all arguments have been parsed.Describe alternatives you've considered
An alternative would be to enable regex-matching for arguments, but that's less powerful than a consume function. If you want regex matching you can still do that from within the consume function
Additional context
I'd be willing on working on this feature if it's desired, but I don't want to work on it if the maintainers oppose the idea as a whole.
A nifty side-effect of using consume is that you can now create commands using an argument setup like this;
[arg1], [arg2], [arg3]
rather than this;
[arg1, [arg2, [arg3]]]
which is the only current way to implement optional arguments. This could be achieved by consuming 0 characters, handing over the entire, unmodified argument string to the next argument in the list.
The text was updated successfully, but these errors were encountered: