Optional arguments are currently gobbling up valid subcommands. For example, when a user tries ab cd and cd is a command but ab has optional data, optional takes precedence and gobbles when it shouldn't. This issue was taken from these two old and quite ambiguous comments:

// TODO: optional is gobbling others, need to maybe peek and check
// TODO: rewrite data

If I try to use an argument with a hypen in it, I get a compile error like:

error[E0609]: no field `args` on type `&argi::Argument<'_>`
  --> bin/main.rs:44:11
   |
44 |     match data!(bool, ctx => --include-methods) {
   |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unknown field

Is this supported? Could it be? Perhaps by specifying the arg in quotes/string...

They currently have a mixture of brute-force matching and TT munching, where we should really only be using TT munching under the current design which is superior. Another speedup would be moving away from the non-functionised part in cli_below!() which is as so:

// recursion-only
($cmd:expr; $($($left:literal),* $(,)? $(:)? { $($tail:tt)* }),* $(,)?) => {
    // etc
}

Doing this would most likely drastically help compiletimes for more complex cli apps, as well as allow easier maintenance.

Manual pages should also be a primary post-release feature, perhaps a little further down the line then #5 as they are still frequently used in modern times. It should not have any message truncation (#2) etc and should be in the man-page format.

Not sure about if this should be a feature gate because the parsing complexity may be quite large due to specific manpage formatting requirements (i.e. the troff format).

Important post-release feature, having a typo correction algorithm implemented helps a lot in my opinion and its a feature I like to see on other argparsers but that's missing from this.

Now that most everything else is finished, argument searching (for both generally and for if only used == true) is a must

https://github.com/Owez/clonk/blob/15e8676fe218f63a4f6ca36f4f33300161f9c2d3/src/lib.rs#L293

Self-explanatory once you read the rest of it; the current .push_str() and format!() system isn't the best and should be replaced by a write!() macro.

The reason why the function itself returns String is to simplify the logistics of getting it's length compared to writing directly to the buffer, due to how the tab_to function works to format help (currently, see #2).

There are many reused sections to both commands and args, see:

pub struct Argument<'a> {
    /// Calls which can be made which instigate this argument
    pub instigators: &'a [&'a str],
    // the following values have been flattened into this and argument and function the same, this is for end user ease of use as the cost of us
    /// Help message, if added, for this argument
    pub help: Help<'a>,
    /// The type of data this argument parses, if any
    pub parses: Option<&'a str>,
    /// Indicates if a user has invoked this argument at any point
    pub used: bool,
    /// User-implemented closure which is ran at parse-time, if added
    pub run: Option<fn(&Self, Option<String>)>,
    /// Raw data found from parsing
    pub data: Option<String>,
}

versus the command:

pub struct Command<'a> {
    pub name: &'a str,
    pub args: Vec<Argument<'a>>,
    pub subcmds: Vec<Command<'a>>,
    // the following values have been flattened into this and argument and function the same, this is for end user ease of use as the cost of us
    /// Help message, if added, for this argument
    pub help: Help<'a>,
    /// The type of data this command parses, if any
    pub parses: Option<&'a str>,
    /// Indicates if a user has invoked this command at any point
    pub used: bool,
    /// User-implemented closure which is ran at parse-time, if added
    pub run: Option<fn(&Self, Option<String>)>,
    /// Raw data found from parsing
    pub data: Option<String>,
}

Only 4 items in total are different (1 for arguments, 3 for commands) and the rest are flattened badly for better user experience, which is now null and void due to the inclusion of the data() command method.

Need to change the cli! curly braces to parens (or otherwise surround the cli! invocation with parens to make an expression) for the README example to compile.

Once compiled, the README example produces no output when run.

Can it be used, for example, to pass entire command line array to a subprocess unmodified without restrictions, like xargs?
Does it start from std::env::args (simpler, but makes this task impossible) or from std::env::args_os (proper way, but tricky)?

The macro should allow [value?] for optional data along with optional: true for long-form inputting. Should then not give data required errors or no commands inputted

Simpler and less prone to weirdness caused by a user potentially submitting "path" instead of path etc; simplifying checks and the library as a whole. The None still acts as a barrier so nothing really changes on that front

When this project is further in development, all public items should be properly and fully documented with high-level examples for all. As for now however, they are purposefully more undocumented then private items.

https://github.com/Owez/clonk/blob/15e8676fe218f63a4f6ca36f4f33300161f9c2d3/src/lib.rs#L145

Arguments formatted as -a are currently allowed but not ones like -ab (which go to both -a and -b) when inputted by a user.

EDIT: the overall issue is still relevant despite the codeblock shown being outdated.

A further extension to .data() fetching should be multiple parts in data like so:

ctx.data("subcmd --argument")

Instead of the current system which is:

ctx.get_cmd("subcmd").data("--argument")

Originally posted by @Owez in #10 (comment)

Before 0.1.0 release, there should be more demos and a restructured examples dir

https://github.com/Owez/clonk/blob/15e8676fe218f63a4f6ca36f4f33300161f9c2d3/src/lib.rs#L185

Currently, we allow infinate length help messages, which are good for command-specific autohelp, e.g. ./program my_command --help, but may not format properly on the overview ./program --help where my_command may be a sub-command. To fix this I propose two changes:

1. If a help message has a newline, only show the first line in the overview message and the full help in the command-specific help
2. Truncate using .. to either fit terminal length or more realistically 80 characters if the total length of the line is >80