A custom command is one which is defined entirely in the customCommands block of config, and has no code supporting it in particular (Rather, all code for custom commands is generic to any configured custom command). Resolving this issue should similarly use a generic solution which examines the elements of config.customCommands, without any special behavior for single commands.
The first step here is to special-case the existing mechanism to generate helptext - Perhaps the topic 'other' (ie Cadence help other) should trigger this?
Whatever topic is chosen, provide a special case to the conditions for recognizing help topics (If config.helpTopics includes a key that matches 'target', then format it's info, else if it equals 'other' print custom command helptext, else print an error) - Or, perhaps, define some way to include it as a key and specify it triggers the custom command generation (I like this better because it's more customizable, but it's a bit more in-depth. My first idea here is to say 'if config.helpTopics[target] == "custom", then fire off this flow', but that is not a requirement)
Once there is a place for custom command helptext to be generated, then add in generation of it. My initial thought of the helptext is to calculate the total number of custom commands, then the text looks like the generated text for other commands:
Text-only commands in CadenceBot
CadenceBot supports \<# commands> which do not have any side effects within the bot.
These commands are:
\
(I am very open to how the title and subtitle could be better phrased)
One command spec essentially has two parts: How to trigger the command, and what the command will do, wrapped up in a somewhat natural sentence. This is something like:
Trigger phrase for command, trimmed for whitespace[any parameters it takes, in <angle brackets>] - Prints a <random or static> response [based on <list parameters> IF PARAMETERS EXIST].
Hence, my proposal for the default-config output would be something like:
Text-only commands in CadenceBot
CadenceBot supports 15 commands which do not have any side effects within the bot.
These commands are:
Cadence introduce yourself - Prints a static response.
Cadence flip a coin - Prints a random response.
Cadence introduce yourself to me - Prints a static response.
Cadence tell me a joke - Prints a random response.
Cadence echo to \ \ - Prints a static response based on \ and \.
Cadence please don't \ - Prints a random response based on \.
Cadence please \ - Prints a random response based on \.
Cadence introduce yourself to \ - Prints a static response based on \.
Cadence am I new boot goofin - Prints a random response.
Cadence am I \ - Prints a random response based on \.
Cadence resolve the debate between \ and \ - Prints a random response based on \ and \.
Cadence cadence - Prints a static response.
Cadence Cadence - Prints a static response.
Cadence echo \ - Prints a static response based on \.
Cadence don't say \ - Prints a random response based on \.
Note that the multitargeted commands don't have to mention when they depend on the author (so the output format is still ignored, but the parse format is useful). They should be assembled by amending parseFormat such that parameters appear as \ and \ rather than %u0 and %u1, then appending it to the command's key (/trigger phrase). The dependencies list should be derived by reading parseFormat though - The parseFormat is arbitrary, and has no need to appear as a list.
Also note that no actual examination of the command's output should ever be necessary - Only examination of its metadata. For example, if "Don't say" was made to statically reply "OK", it's okay if its helptext still says "prints a static response based on \". We can revisit this decision in the future if it becomes annoying.
Finally, note that order of output is completely arbitrary - There is no need to examine them in any particular order.
A custom command is one which is defined entirely in the customCommands block of config, and has no code supporting it in particular (Rather, all code for custom commands is generic to any configured custom command). Resolving this issue should similarly use a generic solution which examines the elements of
config.customCommands, without any special behavior for single commands.The first step here is to special-case the existing mechanism to generate helptext - Perhaps the topic 'other' (ie
Cadence help other) should trigger this?Whatever topic is chosen, provide a special case to the conditions for recognizing help topics (If config.helpTopics includes a key that matches 'target', then format it's info, else if it equals 'other' print custom command helptext, else print an error) - Or, perhaps, define some way to include it as a key and specify it triggers the custom command generation (I like this better because it's more customizable, but it's a bit more in-depth. My first idea here is to say 'if
config.helpTopics[target] == "custom", then fire off this flow', but that is not a requirement)Once there is a place for custom command helptext to be generated, then add in generation of it. My initial thought of the helptext is to calculate the total number of custom commands, then the text looks like the generated text for other commands:
(I am very open to how the title and subtitle could be better phrased)
One command spec essentially has two parts: How to trigger the command, and what the command will do, wrapped up in a somewhat natural sentence. This is something like:
Hence, my proposal for the default-config output would be something like:
Note that the multitargeted commands don't have to mention when they depend on the author (so the output format is still ignored, but the parse format is useful). They should be assembled by amending parseFormat such that parameters appear as \ and \ rather than %u0 and %u1, then appending it to the command's key (/trigger phrase). The dependencies list should be derived by reading parseFormat though - The parseFormat is arbitrary, and has no need to appear as a list.
Also note that no actual examination of the command's output should ever be necessary - Only examination of its metadata. For example, if "Don't say" was made to statically reply "OK", it's okay if its helptext still says "prints a static response based on \". We can revisit this decision in the future if it becomes annoying.
Finally, note that order of output is completely arbitrary - There is no need to examine them in any particular order.