Add support for sub commands

[DRSchlaubi]

You should be able to add sub commands to a command like this

command("main") {
   command("sub") {
     command("subsub") {
     }
   }
}

[BartArys]

It's a frequently requested feature, so I'm not against adding it in some capacity.

One concern is that this is smuggling in multi-word commands, your example would be analogous to:

command("main") {

}

command("main sub") {

}

command("main sub subsub") {

}

if multi-word commands were allowed. The reason why they aren't allowed is one of design, the library would have great difficulty distinguishing between main {WordArgument} {WordArgument} and main sub {IntArgument}:

command("main") {
    
    invoke(WordArgument, WordArgument) { respond("main") }
    
    command("sub") {
        invoke(IntArgument) { respond("sub") }
    }

}

>> !main sub cat
//invoke subcommand first
<< expected an Int

>> !main sub 15
//invoke command first
<< main

This issue can somewhat be mitigated with backtracking, giving preference to the subcommands first and on failure attempt the parent commands. This works (albeit in a rather inefficient way) if there is at least one valid command for the input. If an error occurs though the question as to which error to display comes up. The first? The last? All of them? The one that got the furthest in parsing?

I've got some other minor clarification questions on certain behaviors, but I think it'd be best if we get this issue out of the way first.

[DRSchlaubi]

It's a frequently requested feature, so I'm not against adding it in some capacity.
I was wondering why there is no issue I saw some discussion on the kord dc already

As of the multi world command I don't really see the difference between multi word and sub commands. The only difference is that the sub command would know about it's parents and could inherit something like the preconditions

EDIT: Another advantage about sub commands would be that the command know which names are reserved for sub commands so when you have

!test a
!test b
!test <name>
!test create <name>

You know in the create command that a, b and create are not usable

[BartArys]

As of the multi world command I don't really see the difference between multi word and sub commands

Then I hope you see how subcommands are problematic, as I've explained in the first post.

[Tmpod]

I think the idea of multiword commands isn't really a good one to follow. The lib has to be opinionated on some aspects else it becomes a pain to do anything, and I think you simply shouldn't allow multiword commands. I like the idea of command names following git's style: commands that really need more than one word use dahses as separators and subcommands are separated by whitespace.

As I see it, groups should (optionally) pass down their preconditions, and should also be allowed to have a block of logic that is (optionally) executed when no subcommand is found. This is useful in case you want to show a help page about the group, display current configurations for a certain feature or maybe execute one of the subcommands.
As for the parsing, it shouldn't be difficult, you simply tru to parse subcommands first, and if it doesn't find anything it tries to invoke the group's root logic.

Apologies for the shid English

[DRSchlaubi]

As of the multi world command I don't really see the difference between multi word and sub commands

Then I hope you see how subcommands are problematic, as I've explained in the first post.

as you already mentioned before you can just see if the next argument matches the name of a subcommand and if it does not you use it as an argument in the parent command. I don't think that would cause too many issues

[AllanWang]

^ Agreed with the above. Arguments should have lower priority to other sub commands. With the tree structure, we should know all the options within a given command, and be able to try top down until we succeed. I see this being a problem when sub commands aren't supported, as there isn't really a way to communicate between independent commands.