[Proposal] Remove global options in Powderhouse parser

[KathleenDollard]

We plan to remove global option handling in Powderhouse. We think it more appropriate to put the option on all the things it belongs on and helper methods to add it are simpler than adding code to the core parser.

The Help subsystem will recursively add the option so there will be no change at the functional level for help.

The benefit will be simplifying and possibly speeding up the core parser for a feature that is rarely used except for help.

[KalleOlaviNiemitalo]

Will it support homonymous options in a parent command and its subcommand? Like how git -c core.safecrlf=warn commit -c HEAD -a has two occurrences of -c with different meanings.

[KathleenDollard]

@KalleOlaviNiemitalo If I understand the question, each command has an explicit option attached. The change proposed here is that all options are always explicitly attached.

Each subsystem has an Initialize method that runs before parsing. One of the reasons for that step is to attach symbols. There is an open issue that the Help subsystem needs to add the help option (they can reuse the same option) explicitly.

It also has an Execute method which does the actual work. Symbols do not have actions in the Powderhouse design because invocation is not part of the core parser.

If I understand your question - yes that will work just fine. Thanks for asking. Those kinds of questions are super helpful right now.

[Viir]

Nice! I appreciate the reduction of magic making things more explicit in the configuration.

Explicitly stating that I want to map all subcommands (maybe supplying a predicate to decide whether to descend into a subtree) feels more natural.