Subparsers with subparsers

[h-2]

Yes, unfortunately this is a thing. And I need it. It isn't even possible to emulate this features using a positional at the moment, because I can't add_option based on the value of a positional, because it hasn't been parsed yet 🙈

However, I am also not sure how best to do this, because right now, subparsers are just defined as strings. And they need to be known at construction time. This makes it very difficult.

Let's take git remote as an example. Is there some way, we could do this instead

sharg::parser parser("git", ...);

parser.add_subcommand("remote", ...);

Then it would be trivial, to just call .add_subcommand("add", ...) on the parser returned by parser.get_sub_command() and everything would work recursively automatically.

If we need to define the subparser when constructing the first initial parser, it get super messy.

I mean, it is possible:

struct subcommand_t
{
    std::string cmd;
    std::vector<subcommand_t> subcmds;
};

struct options
{
    std::vector<subcommand_t> subcmds;
};

int main()
{
    options git{.subcmds{{.cmd = "remote", .subcmds{{"add"},
                                                    {"rename"}, 
                                                    {.cmd = "remove", .subcmds{{"foo"}}}}}}};
}

... but it's not pretty.

The other option would be define the parser for git remote add first and then for git remote rename and then pass those to the constructor of the parser of git remote which we then pass to the constructor of the parser of git. But this reverses the definition order, which makes it very unintuitive.

What do you think?

Other arg parsers like CLI11 can do this...

[eseiler]

The main problem is that there is no way to change the subcommands of a parser, and for subparsers, they are set to {}.

But when adding a subparser after the constructor, we also need to re-run the init() function, which requires argc/argv.

I sketched a PR that allows recursive subparsers, but still needs some work: #233

[eseiler]

So the idea of returning the subparser would then be something like this?

Old

sharg::parser git_parser{"git", argc, argv, sharg::update_notifications::on, {"pull"}};
git_parser.parse();

sharg::parser & sub_parser = git_parser.get_sub_parser();

if (sub_parser.info.app_name == std::string_view{"git-pull"})
{
    auto & pull_parser = sub_parser;
    std::string repository{};
    pull_parser.add_positional_option(repository, sharg::config{});
    pull_parser.parse();
}

New

sharg::parser git_parser{"git", argc, argv};

if (auto & sub_parser = git_parser.add_subcommand("pull"))
{
    auto & pull_parser = sub_parser;
    std::string repository{};
    pull_parser.add_positional_option(repository, sharg::config{});
    pull_parser.parse();
}
else
{
    git_parser.parse();
}

[eseiler]

I did all the prerequisite restructuring, but then forgot about the actual feature.
I recently had a use case for recursive parsing, so I remembered.

We merged #233 which allows adding subcommands via void add_subcommands(std::vector<std::string> const & subcommands).

The whole subparser-API is not the prettiest yet, and we might change it in the future, but for now, this was the least-breaking way to implement it.