mrahhal / konsola Goto Github PK

A workaround for now:
When throwing CommandLineException do it as such:

throw new CommandLineException("your error message")
    { Kind = CommandLineExceptionKind.Message };

#5

So that --h/--help won't be handled by Konsola, and instead will be bound to the h/help parameter (if it exists).

We should try and change the design to be more managed and consistent to allow extensibility among other things.

This should probably be the first step to do before anything else.

There is a ParameterKind enum that is used in the help context generator. Reuse it in someway so that we can know the parameter's type anywhere easily.

Things like mandatory parameters, positional ones, and other things can be shown in the default help formatter.

Introduce schemes for different types of parsing requirements.

Example: to be able to support unix-like parsing style.

Currently parameters are outputted in a reverse order according to the inheritance chain. We should output the very first base class' parameters and move from there up the chain.

For example:
* -length instead of * length for a string parameter
* --out instead of * out for a bool parameter

Allow positional parameters to be specified before or after other parameters. Currently positional parameters are parsed correctly only if they come first (others can come after).

Something like:

// RangeAttribute is a custom class extending ConstraintBase.
[Parameter("sv")]
[Range(MinValue = 2)]
public int SomeValue { get; set; }

Constraints would be checked and validated during the binding of arguments.

This was present in the pre v1.0 releases but got removed during the redesign.

For example, show when a parameter is mandatory.

Sometimes value source are being mixed in the wrong way between parameters.