Adding CommandOptions to branch requires options to be defined BEFORE subcommands

[Goffen]

Information

• OS: Windows
• Version: Commit: e4dda28
• Windows terminal

Describe the bug Adding CommandOptions to branch requires options to be defined BEFORE subcommands

To Reproduce Use Demo project and extend AddSettings with this:

        [CommandOption("--quiet")]
        [Description("Quite mode")]
        public bool Quiet { get; set; }

> Demo.exe add wo package pkt --quiet
┌──────────────────┬───────┐
│ Name             │ Value │
├──────────────────┼───────┤
│ PackageName      │ pkt   │
│ Version          │ null  │
│ Framework        │ null  │
│ NoRestore        │ False │
│ Source           │ null  │
│ PackageDirectory │ null  │
│ Interactive      │ False │
│ Project          │ wo    │
│ Quiet            │ False │
└──────────────────┴───────┘

Quit is here FALSE even though I clearly gave it as an option to the command.

Demo.exe add wo --quiet package pkt
┌──────────────────┬───────┐
│ Name             │ Value │
├──────────────────┼───────┤
│ PackageName      │ pkt   │
│ Version          │ null  │
│ Framework        │ null  │
│ NoRestore        │ False │
│ Source           │ null  │
│ PackageDirectory │ null  │
│ Interactive      │ False │
│ Project          │ wo    │
│ Quiet            │ True  │
└──────────────────┴───────┘

Gives Quite = true

Expected behavior I expected CommandOption:s can be assigned anywhere on the commandline. I´ve never seen CLI:s requiring this strict order.

With CommandArguments it's might be more intuitive to assign arguments to each command in order: "X arg1 arg2 Y arg1 arg2". But this cant be the case with options. Examples of usages would be great on the https://spectreconsole.net/cli/composing page

---

Please upvote :+1: this issue if you are interested in it.

[patriksvensson]

@Goffen Thanks for reporting this. Will take a look at it closer when I have some spare time.

[Breakpoint21]

I looked through the codebase and think the problem exists because the way the parser currently works. It walks the commandtree and consumes the tokensteam on the way. Options are only mapped when they are found on the current command or match the help-option https://github.com/spectreconsole/spectre.console/blob/0bf97cb66699369559de8bbfe02f048504db28d3/src/Spectre.Console/Cli/Internal/Parsing/CommandTreeParser.cs#L246-L290

The solution that i came up with is walking back the commandtree up to the root, when parsing options (Maybe only in RelaxedMode) - would this be a good solution?

[PsychoNineSix]

I'm also running into this issue at the moment and it's quite annoying to run in to. This also impacts the --help option, it does not display commandoptions from the branch the command is in.

[PsychoNineSix]

I'm also running into this issue at the moment and it's quite annoying to run in to. This also impacts the --help option, it does not display commandoptions from the branch the command is in.

scratch that! In my (and maybe other users running into this) use case it's enough to remove the settings from the branch, now the order and help of each command works as expected.

[Simonl9l]

@PsychoNineSix Id suggest that it is also valuable to want to place the settings on the branch, and expect the Argument to show as you had originally expected (per --help options) as the argument applies to all subcommands - so I'd say un-scratch!

I assume it is "not normal" to have branch options separated from their sub command options as today all the options are moved to the end regardless of what part of the setting call hierarchy they are in - this implies that there are multiple sets of options, those as part of the branch and this and part of the selected sub command one is looking at --help for?